This is great! The example page on official d3 is a bit dated and certainly has "grown" over time. I also particular don't like that d3 is too much of a "one tool for everything" approach. I.e. the data calculations and the drawings shouldn't be done in the same framework (thats were React comes into play).
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.e. the data calculations and the drawings shouldn't be done in the same framework (thats were React comes into play).
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.
I get your point and tend to agree; the issue I have is that d3 drawing and updating, along with internal events (i.e. d3 custom dragndrop implementation) don't play nicely together with React (or Angular or Vue, for that matter). But I admit, I wouldn't know how to improve on that.
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.