Different for the sake of different is fine, but "preferable" is a bold statement that appears to have no evidence.
Of course, it does have a lot of useful code around math, projections, etc.
This project looks like a very welcome step in the right direction, showing that d3's great math can be used with obvious, declarative syntax.
".enter" actually makes sense in terms of describing how data flows through the D3 processing pipeline.
Quite simply, there's an impedance mismatch.
> "Unfortunately, I always find D3 code surprisingly difficult to understand and extend"
I would say something different - it is very easy to extend and create various visualization. It is easy to scaffold new chart (line, pie, box-plot, heatmap etc.) and customize it to specified needs. I'd rather say that it is difficult to create a brand new type of visualization which wasn't been already developed [1] and it is easy to understand by random folk.
React as an ecosystem is pretty fantastic but the React animation story is still pretty terrible unfortunately. "Portals" / "reparenting" is a majorly hacky way of getting an element from one part of the DOM to another, and even React Motion, which solves a few of the animation gripes, is hard to use, slow, and brittle in my experience. There just isn't a good substitute for the enter-update-exit selections that make up the core of D3.
My usual workflow is to get as much DOM building done in React as I can, with D3 filling out the tricky bits. D3's lifecycles and direct DOM manipulation are much more complicated to reason about than React, on the whole.
RactiveJS uses virtual dom as well, so was quite performant and very easy animations of properties.
I'm hopeful it could do some of the middle bits.
In order to completely avoid JS in the markup, event binding must be done outside of the markup. I do this by using event delegation rather than binding directly to elements.
React.createElement('h1', {}, 'Hello')
The big question is, should it render down to D3's API, or should it implement it in a way that is idiomatic to React, like this demo?
This is not a library, but rather a demonstration that it's possible (and preferable) to use React instead of the core of d3.
In the Readme they say the `style` property is required, and they also don't show any examples of animating something other than style.
As others are alluding to, transitions are not currently so easy to express with React alone. We wrote and recently open-sourced a React component that aims to encapsulate the power and simplicity of d3 transitions (feedback & contributions welcome): https://github.com/dechov/join-transition/
According to the changelog for the recently released version 4.0.0 of D3.js by Mike Bostock[1], one of the big shifts is for D3 v4.0.0 to be "composed of many small libraries that"[2] can be used independently. So the author of D4.js can now more easily examine Bostock's refactored code for Zoom and Drag as they please.
> let React do all the migraine-inducing heavy lifting to figure out what to enter and exit, and have D3 take care of the updates.
https://medium.com/@sxywu/on-d3-react-and-a-little-bit-of-fl...
Wrote an article on this concept last year: http://formidable.com/blog/2015/05/21/react-d3-layouts/
and spoke about it at Reactive2015: https://www.youtube.com/watch?v=n8TwLWsR40Y
Have been doing data visualizations like this ever since, it works. Yes, the hardest part is animation, which we had to address, as well as the axis components and other higher order functionality that builds on d3 itself:
https://github.com/FormidableLabs/victory-animation
http://formidable.com/open-source/victory/docs/victory-axis/
I did that! One function that receives actions for update, create, delete, etc. Now my code is easier to read. Check the function gupChildren (AKA: General update pattern for child nodes of a selection) in my code, and feel free to use it: https://bitbucket.org/aurelito/sandro-lib/src/83b81c4b556848...
At last, unless you understand what you are doing, use selectAll and no select.
Cheers!
For the animations, it is often just a matter of continuosly updating the state of some component, something that I did in this mixin https://github.com/andreaferretti/paths-js-react-demo/blob/m...
- Basically the data fetches get pushed to a lightweight queue/topic system in the browser (using publish.js).
- Each part of the page listens for messages it cares about and updates the page accordingly.
There is still some of the d3 plumbing (I must specify how updates differ from mere element creations, and handle the exits). But I still get a nice decoupling between the different parts of my app. Coupled with browserify, this ends up with semantics not unlike Erlang (I even named the listener method "receive" and it acts on patterns of messages).