8 ms·
I rewrote some charting code at work using this approach, and the benefit really shines through when you're already working with a React codebase. You can basic
by uhoh-itsmaciek 6y ago
I rewrote some charting code at work using this approach, and the benefit really shines through when you're already working with a React codebase. You can basically add most of what D3 can do for you without introducing a separate DOM manipulation paradigm. It doesn't really matter which way of doing it is better: two different ways of doing it are definitely worse.
If you're already a D3 expert or you have a bunch of existing D3 graphs you want to plop into an existing app, sure, you can use the ref approach. But if you want modular, reusable React components to build out an application, the approach Amelia outlines here works great.
- paulgb 6y agoAgreed, and I’d add that the React code tends to be more readable than the equivalent D3 code because the nodes can be a pure function of the state and the virtual DOM will reconcile differences. In D3 the DOM state depends on previous DOM state, so even well-organized D3 code can take a lot of room in your head to understand compared to just looking at a function that spits out a JSX element.
- jiofih 6y agoFor a reason. You can’t achieve a quarter of what D3 can with that approach, especially when it comes to transitions and animations.