from Hacker News

D4 – Declarative Data-Driven Documents

by joelburget on 7/18/16, 12:47 PM with 79 comments

  • by krebby on 7/18/16, 3:38 PM

    This is a good start but it glosses over the hardest part of making React work with D3, which is animations. Most animations you want to do with D3 don't fall neatly into categories you can use with CSS animation (namely updating paths and entering / updating / exiting animations).

    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.

  • by weego on 7/18/16, 2:18 PM

    Sorry, I don't get it. The code in any of the given example comparisons has no less obvious complexity and just removes the abstraction that writes the SVG nodes for you with having to explicitly write them in your JS which I similarly have never understood why we're intent on going back to.

    Different for the sake of different is fine, but "preferable" is a bold statement that appears to have no evidence.

  • by deno on 7/18/16, 3:17 PM

    Hybrid approach:

    > 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...

  • by colinmegill on 7/18/16, 7:53 PM

    Love this - awesome work.

    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/

  • by dechov on 7/18/16, 3:41 PM

    My team and I have been using and finding success with such a pattern for a couple of years now.

    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/

  • by otoburb on 7/18/16, 2:29 PM

    >>There are some pieces of d3 that I would love to use but aren't easily portable. For example, d3-drag and d3-zoom smooth over a lot of the quirks you'd have to deal with when implementing dragging and zooming, but they're only designed to work with d3 selections [...] Ideally we could decouple these libraries from selections, but it might also be possible to mock the selection interface they expect while still using React.

    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.

    [1] https://github.com/d3/d3/blob/master/CHANGES.md

    [2] https://github.com/d3/d3/releases/tag/v4.0.0

  • by aurelianito on 7/18/16, 7:34 PM

    I find that D3 is great, but it needs an abstraction for the general update pattern (https://bl.ocks.org/mbostock/3808218).

    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!

  • by jordache on 7/18/16, 3:19 PM

    argh.. I hate the style of mixing JS with markup language....

  • by jtwaleson on 7/18/16, 2:24 PM

    I'm not sure if this is it, but the world needs a simple way to integrate D3 and React. Looks good at first sight though.

  • by pathsjs on 7/18/16, 3:58 PM

    Shameless plug: I have been proposing this approach for long. I found that the missing piece is how to generate the actual geometric information starting from data, hence I wrote a library to this effect https://github.com/andreaferretti/paths-js

    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...

  • by athenot on 7/18/16, 6:50 PM

    I've done the opposite: use d3 to provide React-like semantics.

    - 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).

  • by koopatrol on 7/18/16, 1:15 PM

    I'm excited to play with this. I wonder what kind of overhead it has. I imagine it would be fairly low.

  • by b34r on 7/19/16, 12:59 AM

    Intelligently-optimized JS animations are generally more performant than CSS ones by an order of magnitude. See Greensock for relevant examples. Side note, your examples don't assign keys to your array-mapped paths, which will emit warnings.

  • by FoeNyx on 7/18/16, 4:41 PM

    @joelburget, btw the "demos" link leads to a 404.

    ( https://github.com/joelburget/d4/demo )

  • by guylepage3 on 7/18/16, 2:39 PM

    Very cool.. My only question is.. Is this "D4.js" a full feature replacement for D3.js? Could be a bit misleading. Might want to have a new name for it? Thoughts?

  • by adamwong246 on 7/18/16, 2:46 PM

    I've been working with a similar approach for a while and I give it my vote of confidence. Much more elegant than d3's awkward data-binding.

  • by nthitz on 7/18/16, 2:34 PM

    d3.transition works on element attributes not just CSS. Wish React had something like that!

  • by choward on 7/18/16, 10:01 PM

    What is this? I can't even scroll.

  • by colemannerd on 7/18/16, 3:05 PM

    I need something exactly like this.