varje gång jag arbetar med ett projekt med visualiseringar reagerar projektledare vanligtvis i skräck när jag säger att jag inte använder D3. Varför är det oro? Varför skulle jag välja att inte använda D3?
När vi svarar på dessa frågor måste vi förstå sammanhanget där D3 skapades., D3 släpptes först 2011, och det var ganska innovativt vid den tiden.
normalt vad du skulle se, är bibliotek som ger grafer ur lådan och med en massiv lista över alternativ. Detta kan fungera, men problemet är att varje gång någon har ett nytt krav måste ett alternativ läggas till och stödjas. Så småningom slutar du med vad som är effektivt ett språk där du använder flera objekt för att definiera en graf. D3 tog ett annat tillvägagångssätt, istället för att ge dig de fullständiga komponenterna, ger det dig datadrivna hjälpfunktioner för att skapa dessa komponenter själv.,
vid denna tidpunkt var bibliotek som jQuery och Backbone populära. Att skapa egna grafer med hjälp av dessa bibliotek skulle ha varit utmanande, särskilt om du vill att de ska vara dynamiska. Webbläsare antog bara nya moderna CSS-standarder som övergångar, och mer moderna egenskaper som flex box var fortfarande åldrar bort från att implementeras.
D3 löste många av dessa problem, och det var utan tvekan det enklaste sättet att genomföra visualiseringar vid den tiden. Men mycket har förändrats sedan dess., Vi har nya moderna ramar som använder mer flexibla och uttrycksfulla begrepp som virtual DOM, och CSS har så många nya möjligheter för layout och animationer.
i stället för att automatiskt hoppa till D3, låt mig lista några anledningar till varför du bör ompröva din användning av den.
Jag har arbetat med D3 många gånger under de senaste åren, och genomfört alla slags visualiseringar med det. Jag förstår de allmänna begreppen om D3, och jag kämpar fortfarande för att arbeta med det. Alla jag arbetade med, från juniorer till seniora Utvecklare, kämpar också med det., Vad många människor, inklusive mig själv gör, är att vi hittar ett exempel på nätet som ungefär matchar vad vi letar efter, och ändra exemplet för att passa våra behov.
om vi vill lägga till några anpassade funktioner, kommer vi förmodligen att göra lite mer sökning och hitta något som ser rätt ut, försöka förstå hur det fungerar och fortsätta ändra det tills det gör vad vi vill att det ska göra.
låter det bekant? Å andra sidan är utvecklare idag mycket bekanta med virtuella DOM-bibliotek och de är bekanta med mallning., Är det inte mer meningsfullt att utnyttja dessa färdigheter, snarare än att införa ett bibliotek som kräver ett helt annat sätt att tänka?
det är lättare än du tror
När du först tänker på att skapa dina egna diagram från början är det vanligt att känna sig orolig och livrädd. Det kanske låter som en mycket komplicerad komponent att skapa, men det är verkligen inte när du bryter ner det. Låt oss ta ett exempel på ett linjediagram. Så här gör du ett linjediagram i D3:
källa: bl.ocksa.,så här skulle jag göra något liknande med Preact:
och CSS:
Source: JSFiddle
det finns en hel del kod, men jag använder bara de verktyg som redan står till mitt förfogande, i det här fallet, my view library som är preact (kan vara vad som helst, reagera, Vue, angular etc) och moderna CSS-verktyg som flexbox.,
D3-exemplet kräver att man lär sig många begrepp om D3. Den senare kräver bara att du använder kunskap du redan har om ditt visningsbibliotek. Jag skulle argumentera för att det är lättare att behålla än D3-exemplet, eftersom alla som känner till view-biblioteket ska kunna hoppa in i kodbasen och börja göra ändringar.
glöm inte buntstorleken
beroende på typ av diagram och hur mycket trädskakning kan optimera ditt paket, kommer D3 i värsta fall att importera 70+ KB kod. Detta kan påverka laddningen av din webbplats., Så medan det är sant att du skriver mer kod än det ursprungliga D3-exemplet, distribuerar du totalt sett mindre kod än om du hade använt D3.
i allmänhet är det alltid viktigt att komma ihåg kostnaderna för att använda den koden när du använder kod från tredje part. Om du bara behöver en enda funktion från ett bibliotek, skulle du importera hela biblioteket för den funktionen?, Ja, du borde inte alltid uppfinna hjulet igen, men du måste överväga tiden för att lära dig det biblioteket, storleken som det lägger till i ditt paket, licensen för det biblioteket, det stöd som biblioteket kommer att ha, underhållarnas trovärdighet, förmågan att fixa buggar i rätt tid etc.
Canvas och HTML är ofta bättre än SVG
om du har märkt i exemplet tidigare använde vi en kombination av HTML och SVG. Av någon anledning kommer folk att försöka genomföra hela diagram med SVGs, men det finns verkligen ingen anledning att. CSS är mycket kraftfullare än SVG dessa dagar.,
SVG stöder till exempel inte inslagning av text. Om vi ville göra textförpackning måste vi beräkna den i JavaScript:
källa: bl.ocks.org
med HTML å andra sidan, så länge white-space är inställd på normal, kommer det bara att linda naturligt.
element som cirklar och rektanglar kan göras i HTML och CSS. Du kan använda transform och border-radius för att skapa alla typer av former., Om du ville göra ett stapeldiagram i D3 med två rundade hörn kunde du inte använda rect eftersom det kommer att runda alla fyra hörnen, istället för de två hörnen du ville runda. Ditt enda alternativ skulle vara att använda path.
den enda anledningen till att jag skulle använda SVG-taggar är på grund av path – taggen. Det är fortfarande det enda rena sättet att skapa godtyckliga former utan HTML-motsvarighet.
om du behöver extra prestanda finns det också taggen canvas att överväga., Med canvas måste du koda grundläggande interaktioner själv, men det kommer med fördel av att inte ha overhead av HTML eller SVG som kan konsumera minne och vara långsammare att uppdatera. Du kan uppdatera de enskilda pixlarna på duken hur du vill, så att du kan optimera din visualisering och skala den. Nya webbläsare API: er som OffscreenCanvas kommer också att bidra till att öka prestanda när de används inuti arbetstagare.
men Canvas skalar inte som SVG?,
en mycket vanlig sak som jag har hört ganska ofta, är att duken inte är lämplig för visualiseringar eftersom den inte skalar lika bra som SVG. Under normal användning av canvas, om du zoomar in eller zoomar ut från en sida eller använder en webbläsare som en högre DPI-skärm, kommer din duk att komma ut pixelated och suddig.
detta händer eftersom när du skapar din duk måste du definiera hur många pixlar du vill att din duk ska rita med., När vi ställer in attributenwidth ochheight kan det se ut som om vi ställer in CSS-storleken, men vi ställer faktiskt in storleken på arbetsytan. Det här är inte samma sak.
normalt skulle dina CSS-pixlar vara inställda på samma storlek som din arbetsyta, men när du zoomar in / ut med din webbläsare ser du samma problem igen. Lösningen är att använda window.devicePixelRatio och skala din duk ritning utrymme.
källa: JSFiddle
med hjälp av pixelförhållandet kan vi öka ritningsutrymmet för duken. Men att öka ritningsutrymmet räcker inte, vi måste också berätta för duken att framtida ritoperationer måste skalas till pixelförhållandet. Detta kommer då att lösa alla skalningsproblem.,
kan du berätta vilka som är duk,och vilka är SVG?
slutsats
som du kan se finns det många anledningar till varför D3 är ganska föråldrad nu för många vanliga användningsfall. Webben har utvecklats avsevärt sedan dess release., Om du gör enkla diagram som munkar, stapeldiagram, linjediagram, scatter tomter, etc, överväga att se om du kan implementera dem med din befintliga ram. Det finns inget riktigt som D3 kommer att ge dig för dessa användningsfall. När det gäller underhåll, din kod kommer sannolikt att vara mer underhållbar snarare än svårare att underhålla, och om du behöver göra några ändringar, bör det vara trivialt att göra dessa ändringar.
det finns ingen anledning för produktchefer att känna sig oroad över att inte använda D3, och du borde inte heller vara orolig.
Tack för att du läste!,
uppdateringar
- artikel uppdaterad för att lägga till ”men Canvas skalar inte som SVG?” avsnitt.