Why mix React with D3?

[Marc Fawzi]

I have a project now where I'm building lots of custom D3 components and realizing that I can build the views to react to lens-scoped part(s) of the app state data structure by running through the generic 'update pattern' in D3, and specifying enter() and exit() cycles.

When it comes to keeping the state decoupled from the DOM in this case it is not the whole DOM state of the component that I need to synchronize in app-state but just the data to be rendered into DOM elements (as lists or SVG path points) and the state of user interaction with the component, e.g. user zoomed or panned the chart so I store the new zoom and pan values in app-state. When the component is re-rendered (e.g. coming back to a the page from another or in session transfer scenarios) I just transition to those app-state-retained values.

IMGUI (immediate mode graphics) is great for driving 2D canvas where some "smart canvas" calculates the diff from app state changes and where app state captures everything that is on the canvas, so applying the diff is applied rather than redrawing the whole canvas is a required optimization, and is a standard technique in game development.

If I make my D3 components spit out SVG path data rather than generate SVG and have an SVG-path-data-to-canvas convertor (not too hard, done that before) then a Virtual Canvas that does the diffing (in raster mode) and patches the current canvas would be great*. 

So it seems like with D3 as the DOM reconciliation engine, I can build an IMGUI model without a Virtual DOM per se.

I never understood why someone would want to mix D3 and React in any non-shallow way, i.e. deep integration. It just means that they're having one DOM manager (or 'differ' if you prefer) inside another. 

Obviously, this is a subtle subject so there are many opinions that may not make total sense, and I'm trying to understand why anyone would want to use React with D3 in any way other than a very shallow integration.

Help me understand if there is a rationale for that.

Thanks.

Marc

[Spencer Kelly]

HI Marc, I agree this is a good conversation to have, and something important to get right.
From what I've seen around, there are two basic approaches to having the two play along:

d3.select( React.findDOMNode(this) ).animate()...

this one uses d3 typically, but the state is now disconnected

requestAnimationFrame( React.render( return d3.line()... ))

this one uses d3 as a svg string factory, and diffs at every frame. pretty crazy,

both are pretty insane, and I'd love to see something that's more lucid.This one looks powerful, but isn't finished.

-spence

[Marc Fawzi]

Oh, that is interesting and I have seen tweenState before but it comes across to me as one way to do in React what we take for granted in D3 rather than what I was hinting at which is that we can build full Reactive UIs not just visualizations that have  single-source-of-truth state data structure to which all D3 views would react (while keeping all DOM mutations purely data driven, so it's fully reactive in that sense)

Are you in SF by any chance? This may be a topic for in person discussion :)

Marc

--
You received this message because you are subscribed to the Google Groups "d3-js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to d3-js+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Khalid Jebbari]

When I mixed React and d3, it allowed me to delegate all dom manipulations to React, and use d3 as an engine to calculate stuff (like ranges, color, scales, layout etc.). This allowed me to use React's shouldComponentUpdate to make UI fast because the data set to display was big. Also, having only one way of creating UI components (whether they're backed by d3 or not) makes coding more consistent.

[Marc Fawzi]

Hi Khalid,

"This allowed me to use React's shouldComponentUpdate to make UI fast because the data set to display was big. "

Speed gains from immutable state diffing targeted at the DOM require the scene you're rendering doesn't change much so the changes to be made are minimal and biggest cost is finding out if the state has changed. But if the state is constantly changing in a major way (large diff on every frame) then no DOM bound tech would help you because the DOM is the bottleneck at large diff sizes, when you have many things changing on the screen as is the case with interactive and real time visualizations..

If you used ImmutableJS to speed up state comparison (faster than dirty checking) that comparison would work faster for large datasets but that is ONLY the diff calculation! If the diff itself is large that would go over the DOM's ability to keep up. Assuming parallel animation of style/attr on same element and many element without CSS3 (taking advantage of D3 excellent animation system) the DOM will die or start to stutter sooner or later. The SVG DOM has performance upper limits on number of concurrent elements that can be animated at once, especially when running multiple parallel transitions on each element. A Canvas with diff-ing would be ideal but even redrawing the whole thing in canvas or webgl is much faster for large diffs. Using canvas also involves the same scheme of letting d3 calculate stuff like ranges, color, scales, layout etc but after getting pure data out of d3 why go back to the bottlenecked DOM? 

[Khalid Jebbari]

Indeed, in my use case I was drawing non animated charts, with very few effects. 

I liked your explanations. Indeed big diffs still produce big DOM changes.  Did you consider using React with a canvas backend ? There's this thing called react-canvas on GitHub. Never tried it though. 

What do you use to do canvas rendering ? Raw APIs ? A lib, like pixie.js ?

You received this message because you are subscribed to a topic in the Google Groups "d3-js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/d3-js/ZdmngGRMNto/unsubscribe.
To unsubscribe from this group and all its topics, send an email to d3-js+un...@googlegroups.com.

[Curran]

In case you haven't seen this, here's another interesting example that integrates React and D3 with linked hover interaction, by Chris Roth:

https://github.com/bgrsquared/d3-react-squared

[Marc Fawzi]

Glad we can share experiences and make sense of things because I'm certainly wanting to learn from the collective experience, especially the unique cases under which something that doesn't make sense starts to make sense... a more rounded experience.

I've only used raw canvas API and there is a WebGL-2D library on github that accepts the canvas API so you can drive it like you drive a canvas element with added performance of WebGL, but it is missing radial gradient. However, it's worth forking and investing time in making it work with the whole canvas API.  

[Marc Fawzi]

Hi Curran

"we try to keep the charting logic all in D3 (such as transitions, etc.)."  is what I noticed in the docs for the link you provided. I have no problem with that approach because it does not attempt to replace D3 DOM reconciliation and animations with React's reconciliation and tweenState etc... 

The title of this email should have been "Why not to use React as D3's view layer"

[Khalid Jebbari]

Glad too, I've always enjoyed  discussing with you so far. 

Indeed d3 is king in graphics oriented data manipulation (at least in the js world). Would love to see some code once you can share something, as I don't master at all d3 and WebGL / canvas drawing.