textvis tech stack

[vlandham]

in order to create these visualization components in a reusable and composable way, a consistent structure and technology stack should be used.

proposal: Each visualization is implement as a React component, using D3 for most of the visualization implementation details.

The full tech stack will include:

• D3.js for visualization code
• React for encapsulating component and handling interactions and data propagation
• Babel for ES6 support
• WebPack for building and style inclusion.
• Lodash for various utility functions
• ESLint and JSCS for linting and consistency

Benefits of this approach include:

• keep each visualization cleanly in its own component
• increase reusability of components in larger projects

Additionally, if a single application were created to combine the multiple visualizations, then having each as a react component would work really well for this.

[arnicas]

OMG - you have to convince me with some examples that React structure will work with newbies who want to modify small bits of code. Or new-to-d3 folks who don't know React. :)

[tafsiri]

@arnicas Could you provide an example of what you mean? Depends on what they are trying to modify, and how 'new' they are. If they are interested in hacking a bit on the visualization piece, that will probably look similar to regular d3 code.

As an example i've been working with this stack in a project where the main visualization piece doesn't depend on react https://github.com/tafsiri/komparator/blob/master/lib/komparator.js (in fact that is becoming its own repo) but in connecting it to other components/rendering it out is encapsulated in a react component https://github.com/tafsiri/komparator/blob/master/src/components/compare-view.jsx

If it turns out we do not have UI elements that affect visualizations or coordination between components, or components using other components then it is possible that we may not need it. Else i'm in favor of using React component approach to structure our and define conventions for how things are instantiated and data passed around.

[arnicas]

Ok - yeah. I think as I come up with use cases/design ideas that seem to mean combining components, I should defer to you guys on the architecture. In V2 if we do go with more on-screen GUI controls, having a good scalable component design seems important. Also that project looks interesting, @yannick :)

[vlandham]

ok. So we have a +1 to go with React for now. Lets do it!