Thoughts on "Using the Platform"

Hi @curran! I wanted to discuss this point with you (and hopefully other data viz folks out there)…

So, it seems that your preferred approach recently is to use D3 to fully produce the visualization including any interactivity around it (e.g., the variable selection menus on the scatterplot), and then use vanilla JS to wrap it all as a “component” that can be integrated in any app.

I can see from a teaching perspective that this design makes the visualizations portable for anyone who asks “but what about [insert framework name]?” But how can that be “better” design when you are building projects instead of teaching?

Also, assuming I am not constrained by an existing codebase and starting from scratch, is it even worth it to use a framework at all at this point?

P.S. I know that there are multiple variables to play a role in such decisions, so I don’t expect a hard answer but rather some insights on the thought process.

Hi @waseem-medhat! This is a great question.

In practice, in my “real world” proprietary projects, I’m usually using React to orchestrate the interactivity (state management), then using D3 for the visualization logic. So, for example, state would be tracked with React (typically via useState), then the state as well as the state setter functions are passed into the D3 logic.

One great thing about this approach is that it scales well to development teams with multiple frontend developers. I’ve often collaborated with folks who know React but not D3, and this approach allowed them to, for example, work on the state and data fetching logic in such a way that it was totally decoupled from the D3 logic. I’ve also worked in teams where another developer knows D3 well, but does not know React. This approach of decoupling the logic allowed them to spin up and be productive quickly by just editing the D3 logic, without any awareness of the outer layers of the React code.

The approach is also good for an organization, because let’s say a new project comes along in 6 months time where it’s done in, say, Svelte and not React. The future team could utilize the isolated D3 logic in a straight up copy-paste migration without having to re-code any of the visualization rendering logic. So in this sense the portability can be useful outside a teaching context.

For new projects, if there is any need for traditional non-SVG UI elements in addition to the visualization at all, I like to start with React. That way the team can fully leverage React for what it’s best at, the non-D3 UI that surrounds the visualization, and the state management.

For new projects that are just visualizations and no surrounding UI, it does make sense to start without using any framework. You’d just need to roll your own state management solution. In cases like this, I do roll my own state management solution, but it’s based on the API of useState, so that the D3 logic can still be compatible with React should you choose to adopt it in the future.

Here’s an example implementation of state management that can be used when React is not used, which has an API compatible with const [state, setState] = useState({}) :

import { viz } from './viz';
let state = {};
const container = document.getElementById('viz');

const render = () => { 
  viz(container, { state, setState });
};
  
const setState = (next) => { 
  state = next(state);
  render();
};

render();
3 Likes

Also here’s a starter repo to demonstrate the approach (with React):

2 Likes

Nice! I like this approach. Definitely worth considering.

I have been contemplating the different approaches recently, and so far, I believe that using a framework inside the viz logic would be perfect if I was working solo… The syntax stylistically feels better to me, specifically with Svelte.

However, your approach seems more attractive for collaboration, because it is very portable (elegantly so, I might add :D). I might have to work with backend developers in the future, in which case trying to integrate a frontend framework on top of the backend framework might be a bit overkill (for relatively small projects at least).

Thank you so much for this!

Thanks! I’m glad you appreciate the approach.

It is my hope that visualizations created using the top level function signature viz(container, { state, setState }); should be interoperable with various frameworks. With React it’s clear, but I think this should also work (in theory) with other frameworks like Svelte or Vue. The challenge is to implement state and setState such that it propagates updates correctly within the framework.

All the best!

2 Likes

I’ve started a repository for documenting how to integrate the exported code with various frameworks https://github.com/vizhub-core/vizhub-rosetta-stone