Documentation for Story interface

[aendra-rininsland]

Are there any good patterns for selecting a particular datum in a visualisation and then storing that in state in order to be able to transition to it in a story, or any docs for making custom templates work well with the story interface in general?

[robinhouston]

Great question! Something we commonly do in our templates is to generate an id (which is used as an element id in the DOM) for a particular datum, which typically includes the row index, and perhaps a series index if it’s a multi-series visualisation. Then we use a state value such as state.highlighted to represent the highlighted datum. Augmenting the data with a row index might look something like:

function update() {
    if (!data.my_dataset.processed) {
       data.my_dataset.forEach((row, index) => row.row_index = index);
        data.my_dataset.processed = true;
    }
    …

Note that, if the dataset is updated (e.g. if you transition to a different slide in a story that contains a different visualisation using the same template, or if you edit the data or data bindings in the visualisation editor), the dataset is regenerated and so would lose the processed flag.

Have I understood the question correctly?

[aendra-rininsland]

Mostly I think! Thanks for the reply. 👍

So, if I understand correctly —

1. When a visualisation has its state modified in the story editor, that state persists on that "slide".
2. When the user navigates from one template to another, draw() is called with whatever state was set on that slide.
3. When the user navigates from one slide to another using the same template, draw() is not called, only update(), which will have the new slide's state attached to it

I imagine this means doing the D3 update pattern in update() to handle the updated state, but I think React will just handle any state changes as props so will handle rerenders automatically. Will try a few things today and get back to you!!

[robinhouston]

You do understand correctly! Everything you say above is true. 👍

We’re starting to think about the best way to integrate with React too, so any ideas you can share would be useful to us as well.

[aendra-rininsland]

@robinhouston Merging #73 would be a good start — JSX works out of the box with ESBuild, you don't have to faff with a bunch of Babel plugins (plus it's an order of magnitude faster in my tests; frankly, the speed increases with ESBuild totally remove any incentive to replace Rollup with Snowpack like I was suggesting a few months ago, and it's a MUUUUUUCH simpler architectural change to the SDK than bolting on Snowpack.).