client reconnect and stream re-request #4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactors
plasma.client/websocket-transport
to recreate the websocket ondisconnect, with an exponential back-off.
An important piece of this is re-
:plasma/request
-ing the known streams onreconnect, so the frontend defstreams continue to consume from the backend once the
client has reconnected.
This supports clients staying connected to streams across server restarts, which
is helpful especially when developing against your own server, or otherwise
restarting it by hand (the current behavior requires a browser refresh to
restore defhandler/defstream usage).
Two new attrs are supported on
plasma.client/websocket-transport
::auto-reconnect?
- defaults to true, disable withnil
orfalse
:on-reconnect
- a function invoked after a successful reconnect.Note thaton-reconnect
is called beforeon-open
for now,and
on-open
is still called when reconnecting - perhaps weshould only invoke one of these.
on-open
is called when firstconnecting (never when reconnecting),
on-reconnect
is called whenreconnecting.
Feel free to call out any style/re-arrangement/refactors - it feels like there
could be a cleaner impl than doing this all in
websocket-transport
, butthere's also a bunch of context to share across the send/open/close/message
funcs, so maybe it's best as is.