elke keer dat ik werk aan een project met visualisaties, reageren projectmanagers meestal als ik zeg dat ik D3 niet gebruik. Waarom is er bezorgdheid? Waarom zou ik ervoor kiezen om D3 niet te gebruiken?
bij het beantwoorden van deze vragen moeten we de context begrijpen waarin D3 is gemaakt., D3 werd voor het eerst uitgebracht in 2011, en het was vrij innovatief op het moment.
wat u normaal gezien ziet, zijn bibliotheken die grafieken uit de doos en met een enorme lijst van opties. Dit kan werken, maar het probleem is dat elke keer dat iemand een nieuwe eis heeft, een optie zou moeten worden toegevoegd en ondersteund. Uiteindelijk krijg je een taal waarin je verschillende objecten gebruikt om een grafiek te definiëren. D3 nam een andere aanpak, in plaats van u de volledige componenten te geven, geeft het u data-driven helper functies om die componenten zelf te maken.,
Op dit moment waren bibliotheken zoals jQuery en Backbone populair. Het maken van je eigen grafieken met behulp van deze bibliotheken zou een uitdaging zijn geweest, vooral als je wilt dat ze dynamisch zijn. Browsers waren nog maar net de invoering van nieuwe moderne CSS-normen zoals overgangen, en meer moderne eigenschappen zoals flex box waren nog leeftijden verwijderd van worden geïmplementeerd.
D3 loste veel van deze problemen op, en het was ongetwijfeld de makkelijkste manier om visualisaties te implementeren op dat moment. Sindsdien is er echter veel veranderd., We hebben nieuwe moderne frameworks die gebruik maken van meer flexibele en expressieve concepten zoals virtuele DOM, en CSS heeft zo veel nieuwe mogelijkheden voor lay-out en animaties.
in plaats van automatisch naar D3 te springen, laat me een paar redenen noemen waarom u uw gebruik ervan zou moeten heroverwegen.
Ik heb de afgelopen jaren meerdere keren met D3 gewerkt en allerlei visualisaties ermee geïmplementeerd. Ik begrijp de algemene concepten over D3, en ik heb nog steeds moeite om ermee te werken. Iedereen waar ik mee werkte, van Junioren tot senior ontwikkelaars, worstelt er ook mee., Wat veel mensen, waaronder ikzelf, doen, is dat we online een voorbeeld vinden dat ongeveer overeenkomt met wat we zoeken, en het voorbeeld aanpassen aan onze behoeften.
als we wat aangepaste functionaliteit willen toevoegen, zullen we waarschijnlijk nog wat meer zoeken, en iets vinden dat er correct uitziet, proberen te begrijpen hoe het werkt, en het blijven aanpassen totdat het doet wat we willen dat het doet.
klinkt dit bekend? Aan de andere kant, ontwikkelaars deze dagen zijn zeer vertrouwd met virtuele DOM bibliotheken en ze zijn bekend met templating., Is het niet zinvoller om die vaardigheden te benutten, in plaats van een bibliotheek te introduceren die een heel andere manier van denken vereist?
het is makkelijker dan je denkt
wanneer je voor het eerst nadenkt over het maken van je eigen grafieken vanuit het niets, is het gebruikelijk om je bezorgd en doodsbang te voelen. Het klinkt misschien als een zeer ingewikkeld onderdeel om te maken, maar het is echt niet als je het afbreekt. Laten we een voorbeeld nemen van een lijndiagram. Hier is hoe je een lijndiagram zou doen in D3:
bron: bl.ocks.,org
zo zou ik zoiets doen met Preact:
en de CSS:
bron: JSFiddle
Er is nogal wat code, maar ik gebruik alleen de tools die al tot mijn beschikking staan, in dit geval, mijn view library die preact is (kan van alles zijn, reageren, vue, hoekig etc), en moderne CSS tools zoals flexbox.,
Het D3 voorbeeld vereist het leren van veel concepten over D3. Dit laatste vereist alleen het gebruik van kennis die je al hebt over je view library. Ik zou zeggen dat het makkelijker te onderhouden is dan het D3 voorbeeld, omdat iedereen die de view library kent in staat zou moeten zijn om in de code base te springen en te beginnen met het maken van wijzigingen.
vergeet de bundelgrootte niet
afhankelijk van het type grafiek en hoeveel boomschudden uw bundel kan optimaliseren, zal D3 in het slechtste geval 70+ KB code importeren. Dit kan gevolgen hebben voor het laden van uw site., Dus hoewel het waar is dat je meer code schrijft dan het originele D3 voorbeeld, verspreid je over het algemeen minder code dan wanneer je D3 had gebruikt.
in het algemeen is het bij het gebruik van code van derden altijd belangrijk om de kosten van het gebruik van die code te onthouden. Als u slechts een enkele functie van een bibliotheek nodig hebt, zou u dan de hele bibliotheek voor die functionaliteit importeren?, Ja, je moet het wiel niet altijd opnieuw uitvinden, maar je moet rekening houden met de tijd om die bibliotheek te leren, de grootte die het toevoegt aan je bundel, de licentie van die bibliotheek, de ondersteuning die bibliotheek zal hebben, de betrouwbaarheid van de onderhouders, de mogelijkheid om bugs tijdig op te lossen, enz.
Canvas en HTML zijn vaak beter dan SVG
Als u eerder in het voorbeeld hebt opgemerkt, gebruikten we een combinatie van HTML en SVG. Om de een of andere reden, mensen zullen proberen om volledige grafieken te implementeren met behulp van SVGs, maar er is echt geen noodzaak om. CSS is veel krachtiger dan SVG deze dagen.,
bijvoorbeeld, SVG ondersteunt standaard tekstafbreking niet. Als we tekstwrapping willen doen, moeten we dit berekenen in JavaScript:
bron: bl.ocks.org
met HTML aan de andere kant, zolang white-space is ingesteld op normal, zal het op natuurlijke wijze worden afgebroken.
elementen zoals cirkels en rechthoeken kunnen worden gedaan in HTML en CSS. U kunt transform en border-radius gebruiken om allerlei vormen aan te maken., Als u een staafdiagram in D3 met twee afgeronde hoeken wilt maken, kunt u rect niet gebruiken omdat het alle vier de hoeken zal afronden, in plaats van de twee hoeken die u wilt afronden. Uw enige optie is path.
de enige reden dat ik SVG-tags zou gebruiken, is vanwege de path tag. Het is nog steeds de enige schone manier om willekeurige vormen te maken zonder HTML-equivalent.
als je extra prestaties nodig hebt, is er ook de canvas tag om te overwegen., Met canvas moet je zelf basisinteracties coderen, maar het komt met het voordeel van het niet hebben van de overhead van HTML of SVG die geheugen kan verbruiken en langzamer kan worden bijgewerkt. U kunt de individuele pixels op het canvas bijwerken zoals u wilt, zodat u uw visualisatie kunt optimaliseren en opschalen. Nieuwe browser API ’s zoals Offscreencanva’ s zullen ook helpen om de prestaties te verbeteren wanneer ze binnen werknemers worden gebruikt.
maar Canvas schaalt niet zoals SVG?,
iets wat ik vaak heb gehoord, is dat canvas niet geschikt is voor visualisaties omdat het niet zo goed schaalt als SVG. Bij normaal gebruik van canvas, als u in-of uitzoomt van een pagina of een browser gebruikt die een hogere DPI-weergave heeft, zal uw canvas eruit komen met pixels en wazig.
Dit gebeurt omdat wanneer u uw canvas maakt, u moet definiëren met hoeveel pixels u uw canvas wilt tekenen., Wanneer we de attributen width en height instellen, kan het lijken alsof we de CSS-grootte instellen, maar we stellen eigenlijk de grootte van de canvas-tekenruimte in. Dit is niet hetzelfde.
normaal zouden uw CSS-pixels op dezelfde grootte staan als uw canvas-tekenruimte, maar wanneer u in-en uitzoomt met uw browser, zult u hetzelfde probleem opnieuw zien. De oplossing is om window.devicePixelRatio te gebruiken en uw canvas tekenruimte te schalen.
bron: JSFiddle
met behulp van de pixelverhouding kunnen we de tekenruimte voor het canvas vergroten. Maar het vergroten van de tekenruimte is niet genoeg, we moeten het canvas ook vertellen dat toekomstige tekenbewerkingen moeten worden geschaald naar de pixelverhouding. Dit zal dan alle van de schaling problemen op te lossen.,
kunt u zien welke canvas zijn en welke SVG?
conclusie
zoals u kunt zien, zijn er tal van redenen waarom D3 nu redelijk verouderd is voor veel voorkomende use cases. Het web is aanzienlijk geëvolueerd sinds de release., Als je doet eenvoudige grafieken zoals donuts, staafdiagrammen, lijndiagrammen, scatter plots, etc, overwegen om te zien of je ze kunt implementeren met behulp van uw bestaande kader. Er is niets echt dat D3 je zal bieden voor die use cases. In termen van onderhoud, uw code zal waarschijnlijk meer onderhoudbaar in plaats van moeilijker te onderhouden, en als je nodig hebt om wijzigingen aan te brengen, zou het triviaal moeten zijn om die wijzigingen aan te brengen.
Er is geen reden voor productmanagers om zich zorgen te maken over het niet gebruiken van D3, en u zou zich ook geen zorgen moeten maken.
Bedankt voor het lezen!,
Updates
- artikel bijgewerkt om toe te voegen ” maar Canvas schaalt niet zoals SVG?” sectie.