Hver gang jeg jobber på et prosjekt med visualisations, prosjektledere vanligvis reagerer med forferdelse når jeg sier at jeg ikke bruker D3. Hvorfor er det bekymring? Hvorfor skulle jeg velger å ikke bruke D3?
Når du svarer på disse spørsmålene, må vi forstå konteksten som D3 ble opprettet., D3 ble først utgitt i 2011, og det var ganske nyskapende på den tiden.
det du Normalt ville se, er biblioteker som grafer ut av esken, og med en massiv liste av alternativer. Dette kan fungere, men problemet er at hver gang noen har et nytt krav, et alternativ ville ha for å bli lagt til, og som støttes. Til slutt ender du opp med hva som er effektivt et språk der du bruker flere objekter for å definere en graf. D3 tok en annen tilnærming, i stedet for å gi deg full komponenter, det gir deg data-drevet helper funksjoner for å skape de komponenter selv.,
På denne tiden, biblioteker som jQuery og Ryggraden var populære. Å lage dine egne grafer ved hjelp av disse bibliotekene ville ha vært en utfordring, spesielt hvis du ønsker dem til å være dynamisk. Nettlesere var bare å vedta nye moderne CSS standarder som overganger, og mer moderne egenskaper som flex boksen var fortsatt aldre fra å være implementert.
D3 løst mange av disse problemene, og det var uten tvil den enkleste tilnærmingen til å implementere visualisations på den tiden. Men mye har endret seg siden da., Vi har nye og moderne rammeverk som bruker mer fleksibel og uttrykksfulle konsepter som virtual DOM, og CSS har så mange nye muligheter for utforming og animasjoner.
Snarere enn å automatisk hoppe til D3, la meg liste opp noen få grunner til hvorfor du bør revurdere din bruk av den.
jeg har jobbet med D3 mange ganger i løpet av de siste flere år, og gjennomført all slags visualisations med det. Jeg forstår den generelle begreper om D3, og at jeg fortsatt sliter med å jobbe med det. Alle jeg jobbet med, fra junior til senior utviklere, som også sliter med det., Hva mange mennesker, inkludert meg selv gjør, er at vi finner et eksempel på nettet som omtrent samsvarer med hva vi leter etter, og endre eksempel for å dekke våre behov.
Hvis vi ønsker å legge til noen tilpasset funksjonalitet, vil vi sannsynligvis gjøre noen mer å søke, og finne noe som liksom ser riktig, forsøk på å forstå hvordan det fungerer, og holde modifisere den til den gjør det vi vil den skal gjøre.
høres dette kjent ut? På den annen side, utviklere i disse dager er svært godt kjent med virtuelle DOM biblioteker og de er kjent med templating., Gjør det ikke være mer fornuftig å utnytte de ferdigheter, heller enn å innføre et bibliotek som krever en helt annen måte å tenke på?
Det er enklere enn du tror
Når du først tenke på å lage dine egne kart fra bunnen av, er det vanlig å føle seg bekymret og livredd. Det kan høres ut som en veldig komplisert komponent for å opprette, men det er egentlig ikke når du bryte det ned. La oss ta et eksempel på en linje i diagrammet. Her er hvordan du ville gjøre et linjediagram i D3:
Kilde: bl.ocks.,org
Her er hvordan jeg ville gjøre noe som dette ved hjelp av Preact:
Og CSS:
Kilde: JSFiddle
Det er litt av en bit av koden, men jeg er bare ved hjelp av de verktøy som allerede er til rådighet, i dette tilfellet, mitt syn bibliotek som er Preact (kan være alt selv, Reagere, Vue, Kantete etc), og moderne CSS verktøy som flexbox.,
D3 eksempel krever læring mange begreper om D3. Sistnevnte krever bare bruker kunnskapen du allerede har om du vil vise bibliotek. Jeg vil hevde at det er enklere å vedlikeholde enn D3 eksempel, som alle som kjenner vise bibliotek skal være i stand til å hoppe inn i kodebasen, og begynner å gjøre endringer.
ikke glem om bunt størrelse
Avhengig av diagrammet, og hvor mye treet-risting kan optimalisere din pakke, D3 i verste fall vil være å importere 70+ KB kode. Dette kan ha innvirkning på lasting av nettstedet., Så mens det er sant at du skriver mer kode enn den opprinnelige D3 eksempel samlede du distribuere mindre kode enn om du hadde brukt D3.
generelt sett, når du bruker tredjeparts kode, det er alltid viktig å huske på kostnadene ved å bruke denne koden. Hvis du bare trenger en enkel funksjon fra et bibliotek, kan du importere hele biblioteket for at funksjonaliteten?, Ja, du bør ikke alltid re-oppfinne hjulet, men du trenger ikke å tenke på deg tid til å lære at bibliotek, størrelsen det legger til din pakke, vil lisensen for at bibliotek, støtte for at biblioteket skal ha, påliteligheten til vedlikeholdspersonell, evnen til å løse problemer på en riktig måte, osv.
Lerret og HTML er ofte bedre enn SVG
Hvis du har lagt merke til i eksempelet tidligere, vi har brukt en kombinasjon av HTML og SVG. For noen grunn, folk vil prøve å gjennomføre hele diagrammer ved hjelp av SVGs, men det er egentlig ingen grunn til. CSS er langt kraftigere enn SVG i disse dager.,
For eksempel, SVG ikke har innebygd støtte for tekstbryting. Hvis vi ønsket å gjøre tekst-innpakning, ville vi ha for å beregne det i JavaScript:
Kilde: bl.ocks.org
Med HTML-på den annen side, så lenge white-space er satt til normal, det vil bare pakk naturlig.
– Elementer som sirkler og rektangler kan være ferdig i HTML og CSS. Du kan bruke transform og border-radius for å lage alle slags former., Hvis du ønsket å gjøre en bar chart i D3 med to runde hjørner, vil du ikke kunne bruke rect fordi det vil rundt alle fire hjørner, i stedet for de to hjørnene du ønsket å runde. Det eneste alternativet ville være å bruke path.
Den eneste grunnen til at jeg ville bruke SVG-koder, er på grunn av path – tag-en. Det er fortsatt bare ren måte å skape vilkårlige former uten HTML tilsvarende.
Hvis du trenger ekstra ytelse, det er også canvas – tag-en for å vurdere., Med lerret du er nødt til å kode grunnleggende vekselsvirkningene selv, men det kommer med fordelen av å ikke ha overhead av HTML eller SVG som kan konsumere minne og være tregere til å oppdatere. Du kan oppdatere den enkelte punkter på lerretet, men du ønsker, så du kan optimalisere din visualisering og skalere det. Ny nettleser Api-er for eksempel OffscreenCanvas vil også bidra til å øke ytelsen når den brukes inne Arbeidere.
Men Lerret ikke skala som SVG?,
En veldig vanlig ting som jeg har hørt ganske ofte, er at lerretet er ikke egnet for visualisations fordi den ikke er i skala, samt SVG. Under normal bruk av lerret, hvis du vil zoome inn eller zoom ut av en side eller bruk en webleser som en høyere DPI skjerm, ditt lerret vil komme ut kornete og uklare.
Dette skjer fordi når du oppretter din lerretet, må du angi hvor mange punkter du ønsker arbeidsområdet til å tegne med., Når vi setter attributter width og height det kan se ut som vi er innstillingen CSS størrelse, men vi er faktisk å sette størrelsen på lerretet tegning mellomrom. Dette er ikke det samme.
Vanligvis CSS punkter vil være satt til samme størrelse som din lerret tegning plass, men når du zoomer inn/ut med nettleseren din, vil du se det samme problemet igjen. Løsningen er å bruke window.devicePixelRatio og skalere lerret tegning mellomrom.
Kilde: JSFiddle
du Bruker pixel forholdet, kan vi øke tegning mellomrom for lerretet. Men øke tegning plass er ikke nok, vi må også fortelle lerret at fremtidige tegning operasjoner må skaleres til pixel-forhold. Dette vil da løse alle tilpasningsproblemer.,
Kan du fortelle hvilke som er lerretet, og hvilke som er SVG?
Konklusjon
Som du kan se, det er mange grunner til hvorfor D3 er ganske utdatert nå for mange vanlige bruksmåter. Internett har utviklet seg betydelig siden utgivelsen., Hvis du gjør enkle diagrammer som donuts, bar diagrammer, linjediagrammer, scatter plott, etc, bør du vurdere å se hvis du kan implementere dem ved hjelp av din eksisterende rammeverk. Det er ingenting virkelig at D3 vil gi deg for de bruksmåter. I form av vedlikehold, din kode vil trolig være mer stabile snarere enn mer vanskelig å opprettholde, og hvis du trenger å gjøre noen endringer, bør det være trivielt å gjøre disse endringene.
Det er ingen grunn for produktet ledere til å føle seg bekymret for ikke å bruke D3, og du bør ikke være redd heller.
Takk for at du leser!,
Oppdateringer
- Artikkel oppdatert for å legge til «, Men Lerret ikke skala som SVG?” del.