More idiomatic support for reactive data updates (via reagent atom/reaction data inputs)

[metasoarous]

This issue is being peeled off from #95.

Now that #167 has been resolved, it is possible to take advantage of the Vega View API (via the :view-callback option of the reagent components) to update datasets without completely re-embedding the visualization from scratch. However, this is hardly straightforward or idiomatic.

Issue #172 would offer the ability to stream data into the visualization via a core.async channel, which would certainly be much more performant for applications where this makes sense. We might be also be able to look at a similar API which streams changesets (al a view.change). But both of these patterns only make sense in very specific cases.

What is not clear right now is whether using view.data to change an entire dataset will be significantly more performant than just re-embedding the visualization from scratch (which is currently possible by just dereffing a data atom inline in the spec passed to the oz reagent components). i'm kind of skeptical that it will be, since most of the time presumably gets eaten up with actual rendering, and not so much with abstract processing of the specification. So it's possible that focusing on the streaming cases is our best move for now.

Nevertheless, it's worth spiking out a couple of experiments just to verify whether or not this is the case (which again, should be possible now that we have #167 resolved). It also may still be a useful feature for situations where there are multiple datasets being used in a visualization, where only one of them needs to actually change at any given time. Moreover, it could be useful to update the dataset while leaving any visualization state (like signal control selections) unchanged.

The way I think this would probably work is that you could pass in a reagent atom (or reaction) in the place of a set of data values, and the oz component logic would walk the specifications looking for these values specified as :data (which might not be top level, but could be nested in a layer, or a dataset), deref them for the sake of initializing the visualization, and do something smart with the will-component-update method definition to check whether the specification itself has changed, or whether we're just looking at changed data. If we are just looking at changed data, we can use view.data to update the visualization. However, it's worth noting that to use view.data, the data must be specified as a dataset, as you'll need to pass the name of the data to view.data. For starters, we could only support this functionality if your spec explicitly uses datasets, but it would be nice to support papering over these details eventually. There is a question about whether {:data data-atom ....} or {:data {:values data-atom}} would be supported, but it's probably fairly harmless to support both.

In summary, this is probably something worth spending time on, but in my estimation lower priority than streaming support (#172), and more work to get right. Still, I'm happy to be proven wrong about the performance implications, and even more happy to accept a PR if this is important to someone. You can also let me know if you think one of the use cases described above would be useful to you, and I reprioritize accordingly.