Many JS libraries exist to build graphs on the web (Vega, chartJS, Plotly...).
They allow to make charts quickly. But you lose flexibility: you're limited by the options they offer.
I just created a gallery with hundreds of graphs made with d3.js and React. - Examples are split by graph types - They all come with explanation and code sandboxes - Gradual complexity to ease the learning curve
It took me ages to create this project! Feedback welcome!
The approach is kind of in-between what I suggest and what a classic JS library like Vega does.
It is definitely a very good abstraction imo!! But I'm always scared to be stuck with a customisation I cannot do because of a layer of abstraction.
My biggest pet peeve with D3 is the lack of TypeScript friendly-ness. I not only mean the lack of official typescript .d.ts bindings, but the API itself is completely not designed for strict typing. Functions are heavily overloaded/polymorphic, take all sort of different types of parameter shapes, and change their return values on what is passed in etc. My experience was always, once I got my code "properly" typed, the next update of the .d.ts bindings would break again, and this would repeat every couple of weeks.
I used to think so too; but I don't any longer. Rendering in React is fairly expensive. It may easily turn out that direct DOM manipulation is better suited to visualizations than DOM manipulation through React.
Directly manipulating the SVG DOM with D3 (wrapped in a React blackbox) goes to around 100,000 nodes. After that you really have to start using canvas or webgl.
At those numbers you also start getting huge performance gains by mutating data and doing less copying. Everything you learn in “how to do react” tutorials quickly starts being wrong when your arrays have thousands of elements.
Edit: there’s also a lot you can do with how things are nested. The flatter your DOM, the fewer nodes React has to touch for every update
Here’s a fun stress test I built a while back that goes up to a million nodes rendered by React https://swizec.com/blog/a-better-react-18-starttransition-de...
I will write more about performance soon. But using several layers of canvas is definitely the way to go in most situation to put it in a nutshell
- if you zoom out to show the world, map projections wrap around the antimeridian (e.g. you turn right at Kamchatka, loop around and hit Alaska.) if you want your edges to wrap (i.e. follow a great arc) rather than taking the long way around (i.e. drawing a line all through Europe and Asia), you have to do spherical math.
- if you want a multigraph (multiple edges between any pair of nodes), you need to have a way for those edges to "curve" rather than following a straight path (great arc.) this makes the math much more complicated, especially keeping numerical stability and accounting for coordinate singularities.
- now imagine all the fiddly bits of making the arrowheads touch the nodes at the right place, scale in width properly, etc. if you're really committed, you'll use lat/lon for every vertex of every poly you render. if not, there will be distortions. it's a trade-off.
- now imagine updating all of that while panning and zooming, and keeping it efficient and smooth.
I made a component for this, I'll try to open-source it, but I'm curious how other people have tackled the same issue. Did I just over-engineer the hell out of it doing spherical trig, vector math and iterative methods, or is it plain hard?
I haven't seen that before - very cool.