i think i was originally worried that swapping into view-data directly
would cause unnecessary component re-renders, but that should not ever
happen because application code should not be dereferencing view-data
directly (should always be using cursors).
reagent-data-view's reconnection handling code in on-open that was
intended to make sure active components have their views resubscribed
was also erroneously running on the first connection at page-load time
if some components happened to render before the client/server messaging
system (browserchannel/sente) connected. this caused the view-data
atom's state to get set up in a way that when on-open! was called when
that first connection was finally established on page load, it would
look like there were existing subscriptions that had to have
re-subscription messages sent as if we were processing a reconnection.
we simply track whether on-open is being called for the first connection
or not to handle this properly.
new "architecture" will rely on secondary "adapter" libraries that
plug in to reagent-data-views and provide the actual underlying
client/server messaging implementation (e.g. browserchannel or sente)
Gered