nsplash
hver gang jeg arbejder på et projekt med visualiseringer, reagerer projektledere normalt i rædsel, når jeg siger, at jeg ikke bruger D3. Hvorfor er der bekymring? Hvorfor skulle jeg vælge ikke at bruge D3?
Når vi besvarer disse spørgsmål, skal vi forstå den kontekst, hvori D3 blev oprettet., D3 blev først udgivet i 2011, og det var ret innovativt på det tidspunkt.
normalt, hvad du ville se, er biblioteker, der giver grafer ud af boksen og med en massiv liste over muligheder. Dette kan fungere, men problemet er, at hver gang nogen har et nyt krav, skal en mulighed tilføjes og understøttes. Til sidst ender du med, hvad der effektivt er et sprog, hvor du bruger flere objekter til at definere en graf. D3 tog en anden tilgang, i stedet for at give dig de fulde komponenter, giver det dig datadrevne hjælpefunktioner til selv at oprette disse komponenter.,
på dette tidspunkt var biblioteker som j .uery og Backbone populære. Oprettelse af dine egne grafer ved hjælp af disse biblioteker ville have været udfordrende, især hvis du vil have dem til at være dynamisk. Bro .sere vedtog kun nye moderne CSS-standarder som overgange, og mere moderne egenskaber som fle.Bo. var stadig aldre væk fra at blive implementeret.
D3 løste mange af disse problemer, og det var uden tvivl den nemmeste tilgang til implementering af visualiseringer på det tidspunkt. Imidlertid har meget ændret sig siden da., Vi har nye moderne rammer, der bruger mere fleksible og ekspressive koncepter som virtual DOM, og CSS har så mange nye muligheder for layout og animationer.
i stedet for automatisk at hoppe til D3, lad mig nævne et par grunde til, hvorfor du bør genoverveje din brug af det.
Jeg har arbejdet med D3 adskillige gange i løbet af de sidste mange år og implementeret alle slags visualiseringer med det. Jeg forstår de generelle begreber om D3, og jeg kæmper stadig for at arbejde med det. Alle jeg arbejdede med, fra juniorer til seniorudviklere, kæmper også med det., Hvad mange mennesker, inklusive mig selv gør, er, at vi finder et eksempel online, der stort set matcher det, vi leder efter, og ændre eksemplet, så det passer til vores behov.
hvis vi vil tilføje nogle brugerdefinerede funktioner, vil vi sandsynligvis gøre noget mere søgning og finde noget, der ser korrekt ud, forsøge at forstå, hvordan det virker, og fortsæt med at ændre det, indtil det gør, hvad vi vil have det til at gøre.
lyder dette bekendt? På den anden side er udviklere i disse dage meget fortrolige med virtuelle DOM-biblioteker, og de er bekendt med templating., Er det ikke mere fornuftigt at udnytte disse færdigheder, snarere end at indføre et bibliotek, der kræver en helt anden måde at tænke på?
det er nemmere end du tror
Når du først tænker på at oprette dine egne diagrammer fra bunden, er det almindeligt at være bekymret og bange. Det lyder måske som en meget kompliceret komponent at oprette, men det er virkelig ikke, når du bryder det ned. Lad os tage et eksempel på et linjediagram. Sådan gør du et linjediagram i D3:
kilde: bl.ocks.,org
Her er hvordan jeg ville gøre noget som dette ved hjælp af Preact:
og CSS:
kilde: JSFiddle
der er en hel del kode, men jeg bruger kun de værktøjer, der allerede er til min rådighed, i dette tilfælde mit synsbibliotek, som er preact (kan dog være noget, reagere, vue, vinkel osv.) og moderne CSS-værktøjer som fle .bo..,
D3-eksemplet kræver at lære mange begreber om D3. Sidstnævnte kræver kun at bruge viden, du allerede har om dit visningsbibliotek. Jeg vil hævde, at det er lettere at vedligeholde end D3-eksemplet, da enhver, der kender visningsbiblioteket, skal kunne hoppe ind i kodebasen og begynde at foretage ændringer.
glem ikke bundtstørrelsen
afhængigt af typen af diagram og hvor meget trærystning kan optimere dit bundt, vil D3 i værste fald importere 70+ KB kode. Dette kan have indflydelse på indlæsningen af dit .ebsted., Så selvom det er sandt, at du skriver mere kode end det originale D3-eksempel, distribuerer du generelt mindre kode, end hvis du havde brugt D3.
generelt er det altid vigtigt at huske omkostningerne ved at bruge denne kode, når du bruger tredjepartskode. Hvis du kun har brug for en enkelt funktion fra et bibliotek, ville du importere hele biblioteket til den funktionalitet?, Ja, du skal ikke altid opfinde hjulet igen, men du skal overveje tiden til at lære det Bibliotek, den størrelse, det tilføjer til dit bundt, licensen til det Bibliotek, den support, som biblioteket vil have, vedligeholdernes troværdighed, evnen til at rette fejl i tide osv.
lærred og HTML er ofte bedre end SVG
Hvis du har bemærket i eksemplet tidligere, brugte vi en kombination af HTML og SVG. Af en eller anden grund vil folk forsøge at implementere hele diagrammer ved hjælp af SVGs, men det er virkelig ikke nødvendigt. CSS er langt mere kraftfuld end SVG disse dage.,
for eksempel understøtter SVG ikke indbygget tekstindpakning. Hvis vi ville gøre tekstindpakning, skulle vi beregne det i JavaScript:
kilde: bl.ocks.org
med html på den anden side, så længe white-space er indstillet til normal, vil det bare pakke naturligt.
elementer som cirkler og rektangler kan gøres i HTML og CSS. Du kan bruge transform og border-radius til at oprette alle slags former., Hvis du ville lave et søjlediagram i D3 med to afrundede hjørner, kunne du ikke bruge rect, fordi det vil runde alle fire hjørner i stedet for de to hjørner, du ville runde. Din eneste mulighed ville være at bruge path.
den eneste grund til, at jeg ville bruge SVG-tags, er på grund af path tag. Det er stadig den eneste rene måde at skabe vilkårlige former uden HTML-ækvivalent.
Hvis du har brug for ekstra ydelse, er der også canvas tag at overveje., Med canvas bliver du nødt til at kode grundlæggende interaktioner selv, men det kommer med fordelen ved ikke at have overhead af HTML eller SVG, som kan forbruge hukommelse og være langsommere at opdatere. Du kan opdatere de enkelte pi .els på lærredet, som du vil, så du kan optimere din visualisering og skalere det. Nye bro .ser API ‘ er såsom OffscreenCanvas vil også bidrage til at øge ydeevnen, når de anvendes inde arbejdstagere.
men lærred skalerer ikke som SVG?,
en meget almindelig ting, som jeg har hørt ganske ofte, er, at Lærred ikke er egnet til visualiseringer, fordi det ikke skalerer så godt som SVG. Under normal brug af canvas, hvis du zoomer ind eller zoomer ud af en side eller bruger en bro .ser, som en højere DPI-skærm, vil dit lærred komme ud pi .eleret og sløret.dette sker, fordi når du opretter dit lærred, skal du definere, hvor mange pi .els du vil have dit lærred til at tegne med., Når vi indstiller attributterne width og height det kan se ud som om vi indstiller CSS-størrelsen, men vi indstiller faktisk størrelsen på lærredstegepladsen. Det er ikke det samme.
Normalt din CSS pixels ville være indstillet til den samme størrelse som dit lærred tegning plads, men når du zoomer ind/ud med din browser, vil du se det samme problem igen. Løsningen er at bruge window.devicePixelRatio og skalere dit lærredstegningsplads.
kilde: JSFiddle
Ved hjælp af Pi .elforholdet kan vi øge tegnepladsen for lærredet. Men at øge tegningsrummet er ikke nok, vi skal også fortælle lærredet, at fremtidige tegningsoperationer skal skaleres til PI .elforholdet. Dette vil så løse alle skaleringsproblemer.,
kan du fortælle, hvilke der er lærred, og hvilke er SVG?
konklusion
som du kan se, er der mange grunde til, hvorfor D3 er ret forældet nu for mange almindelige brugssager. Internettet har udviklet sig markant siden udgivelsen., Hvis du laver enkle diagrammer som donuts, søjlediagrammer, linjediagrammer, scatter plots osv., kan du overveje at se, om du kan implementere dem ved hjælp af din eksisterende ramme. Der er ikke noget virkelig, at D3 vil give dig for disse use cases. Med hensyn til vedligeholdelse vil din kode sandsynligvis være mere vedligeholdelig snarere end vanskeligere at vedligeholde, og hvis du har brug for at foretage ændringer, bør det være trivielt at foretage disse ændringer.
Der er ingen grund til, at produktledere føler sig bekymrede over ikke at bruge D3, og du bør heller ikke være bekymret.
tak for læsning!,
opdateringer
- artikel opdateret for at tilføje “men lærred skalerer ikke som SVG?” afsnit.