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)
defvc components no longer declare the view-sigs that will be used.
calls to view-cursor within the component's render function now
automatically trigger the component to subscribe/unsubscribe to the
view-sigs being passed to any view-cursor calls.
to know when it requests should be sent to the server to subscribe
and when to unsubscribe (if multiple components subscribed to the same
view-sig, etc)
- includes some related refactorings
- getting a view cursor by view name (not sig) now is limited to a
view-sig lookup within the list of the component's own subscribed
view-sigs instead of the global subscribed view-sig list
Gered