@decentralion, I thought we might want to use a thread here to discuss and coordinate chart design/dev. The goal is to mix the different perspectives/routes to developing the chart to see what we find, then bring it all together so we have a single component for both the App and research. When I have something more technical to offer via a pull request, I’ll do my code write ups there. Hope that sounds right.
Anyhow, we discussed on the call this morning about how we can separate computational components from rendering components (math vs drawing) in anticipation of a React+d3 chart. For example, the ticked() function that gets called ontick from the force simulation intends to update the chart via a d3 based calculation. Before we had d3.selection nodes updated, but we could also have React components updated like this example. So, even though the d3 function is calculating the movement, the function passes the ontick rendering to a React component not a d3.selection.
I think that reflects the demarcation we discussed that will enable me to continue offering you useful d3 code until I get more up to speed with React.
My work plan entails this:
- extend existing JS into Python Jupyter Notebook for @mzargham, with relevant unit testing on the Python functions
- restructure JS code to separate calcs from rendering while incorporating Hackathon functionality
- SVG rendering unit testing
Questions and suggestions welcomed!
1 Like
@decentralion, just a quick follow up to our phone discussion today - I needed a few moments to collect my thoughts as I don’t feel I represented myself very well.
For a researcher, it will be important to have the ability to map different data elements to different chart elements. For example, in the app UI you’re developing, you’ve mapped scores to node size and node color. It’s not a bad decision at all. I’m simply saying that a researcher should have the ability via the chart library/code to map, let’s say, categories to the node color. I think it’s as simple as defining the chart option as a prop with a default behavior, and then give the python programmer the ability to alter that prop to a different behavior (assuming props can be manipulated/abstracted in the way I’m thinking they are - please advise if you think I’m way off). Then the JS _color() function can check the prop when it’s time to render and produce either the interpolated color currently or an ordinal/categorical color. Hope that makes sense.
Then, the other item, there are chart features I’d like to offer researchers that don’t necessarily translate to added value in the App UI (though perhaps they do): voronoi category groupings (to pull categories together in the simulation), pan/zoom, drag/drop. Certainly, I would intend to contribute these after we get the React-Jupyter Notebook framework figured out, but I think they offer exploratory options beyond a single or static view of the various graph objects a researcher may like.
FYI - @mzargham
1 Like
Got it, that makes a lot of sense. In that case, I think we should not invest the effort into having the research codebase use the same visualizer as the main UI. Doing so will make a really big barrier to iteratively experimenting with new visualizations.
Also, I’m orienting the architecture around making it easy to use the graph visualizer as a part of a UI (i.e. communicating updates to other parts of the app, and receiving updates from the rest of the UI). However, from the perspective of prototyping research visualizations, this is unneeded complexity.
2 Likes