And when we talk about data visualization on the web, we pretty much are talking about D3 (seriously, if all you’ve seen of D3 is whacking out some quick histograms, I have to recommend this fantastic D3 v4 course, which takes you deep into the nitty gritty of what this library is actually capable of. Spoiler: it’s pretty nuts. PS: I am not affiliated with that course in any way, I just took it and dug it).But, a TRAGEDY looms ahead: apparently you can only have one of these awesome libraries in your codebase at a time, right?See, part of what makes React so fast and light is that it is super clever at updating the DOM efficiently, and so when you use React, you mostly don’t touch the DOM directly — you just chill out and let all that sweet, declarative MVC jazz take care of everything for you.Whereas D3 is all about giving you nice clean routes directly to DOM manipulation.So that overlap of implementation is what can potentially cause problems for us — if you don’t plan it properly, React and D3 can just…get in one another’s way, and behave really unpredictably..You can check out the code here or play around with the toy itself here.a relatively simple Controller Component, which renders a form and keeps track of form submission results in its state.Like with the cats, I want to give React and D3 their own separate spaces where they can be in charge and do what they do, and this works really well with a “React-y” way of thinking — we want to assign each library an appropriate role, and isolate the work of that role (and therefore the library) into separate components..This way, when we want to know who gets to manipulate the DOM, the answer becomes really simple: whose component are we in?React is great at interactivity, state management and structuring user interfaces, and so that’s what I’m going to let it do — in this component shown above, Controller..And that’s all we’re doing here — there’s no SVGs, and we haven’t even imported d3 into this file.All of that gets managed down on line thirty nine, where “Viz” is a child component whose sole job will be to take the data that the Controller generates, and use D3 to draw pictures with it.While technically we could reverse these roles (people do, for instance, build entire UI’s that only use D3), the point is to get the best out of each library, and this, to me is the most logical breakdown.a teeny, tiny, tidy, twelve-line Viz component, which renders a single, empty divThe D3 component, Viz, is going to be super small, even though the visualization we’re using it to make is going to take up the vast majority of the viewport — we don’t want React to get involved or have access to it, so all we really need is a single reference point — that empty Div on line thirteen..Both because it’s a good way to ensure that D3 can work at the highest level, and also because it’s a good way to ensure that whoever next touches your codebase has an idea of what’s going on and how to effectively build on it.Because D3 is going to be touching the DOM directly, outside of React’s Model-View-Control jam, it doesn’t have to know anything about the component where it will eventually be called — it has nothing to do with overall React structure of the application, and can live perfectly comfortably in some helpers.js file somewhere..Just like we don’t reference D3 in our React space, we’re not going to reference React here.The big key in all of this is that everything that D3 touches gets created here, and lives only here..( Did you know by the way that you can generate color scales that will map on to whatever numeric values you use as the range? It’s pretty wild.)Before we move on, just a quick note on accessibility: There are a few things you can do relatively easily to give a broad range of users the fullest experience when they encounter your application.First: did you know that SVG’s have a <title> element, which can be set to function similarly to alt text for images?.And we don’t have to worry about React interfering, because, effectively, React doesn’t even really know that our SVG is there — it just receives new props and does what it’s told.If you were doing this last year (or indeed, you read my first article on getting React and D3 to behave themselves when hanging out), you might remember this process being a tiny bit more complicated — where you had to use shouldComponentUpdate to manually turn off React re-renders, and componentWillReceiveProps to handle your redraws with nextProps before they have even, strictly speaking become this.props..React has promised us that classes aren’t going anywhere for the foreseeable future, and I don’t particularly want them to, but it is pretty cool to have another option available.I hope this quick essay has illustrated how easy and un-intimidating using D3 in your React applications can be (and by the way, this is a pretty good roadmap for using React with any third party library that plays fast and loose with DOM) — has it inspired you to make cool stuff with it?. More details