It'll require some work on your end but D3.js should give you what you need. https://d3js.org/

I assume the payload from the AJAX call is stored in state somewhere (and this is a single-page app)? If so, when you the user goes back to the list of blog posts, reset the state value which stores the AJAX payload. Or, another approach would be to store the AJAX payloads as keyed by the ID of the blog post.

Check out React Resolver: https://github.com/ericclemmons/react-resolver

I highly suggest using Enzyme to test React components: https://github.com/airbnb/enzyme And if you like chai, use this along with it: https://github.com/producthunt/chai-enzyme

Since Radium styles are just Javascript objects, its very easy to maintain files that act as a source of truth for things like colors, etc. and import those into your stylesheets. Here's a trivial example: // example-stylesheet.js import colors from './colors' ; export default { link: { color: colors.blue }, }; // colors.js export default { blue: 'rgb(66, 130, 226)' } // example-component.jsx import React, { Component } from 'react' ; import Radium from 'radium' ; import style from './example-stylesheet' ; class ExampleComponent extends Component { render() { return ( < a href = "#" style = {style.link} > Link Text </ a > ) ; } } export default Radium(ExampleComponent); In this case, colors.js is a file in the same directory and project as example-component.jsx , but you could move it to a different folder (to make it easier for other components in the same project to consume it), or even to its own node module (with other similar common style rules) to make it easy for other apps to consume those same rules.

My team has been using Radium to style components we are building for an internal component library. Pros: Consuming applications don't have to worry about separately importing a stylesheet for each component, as components come with their own styles baked in. And since the stylesheets are Javascript files, no additional config changes in the consuming applications are needed. Since styles are inline, don't have to worry about outward style pollution from poorly written css. Unwanted inward style pollution from the page the components live on can happen, but its been fairly minimal for us (usually from poorly written rules that are too general). Writing per-component stylesheets (whether in CSS or JS) promotes modularity and helps reduce dead code. Cons: Only a few of the pseudo-selectors (hover, focus, active) are natively supported right now in Radium. We've had a hard time getting media queries working properly, likely in part due to the fact our consuming applications don't use Radium themselves. For now, we've resorted to computing browser width in JS and passing down states (e.g. isMobile, isTablet, etc) to the components as props (not preferable, but it works). Update: We've been able to get media queries working properly across all of our projects, and its made mobile styling much easier. Radium works great at a component level (especially for a component library), but I don't think it scales well to large applications yet (in terms of using it exclusively to manage styles). Other tools mentioned here may do a better job of that.