Send diffs for presence #658
Conversation
|
View Vercel preview at instant-www-js-presence-diffs-jsv.vercel.app. |
…n up session data after disconnect
tonsky
force-pushed
the
presence-diffs
branch
from
e85bd73 to
ddb2db7
Compare
|
Main functionality is working. Two more things:
|
| (handle-event store-conn event))) | ||
| (defn init-hz | ||
| ([store-conn] | ||
| (init-hz {})) |
There was a problem hiding this comment.
Assuming here we want to do init-hz store-conn {} 🫡
| (conj entries-to-process last-entry))) | ||
|
|
||
| (defn straight-jacket-process-receive-q-batch [store-conn eph-store-atom batch metadata] | ||
| (defmulti consolidate |
| @@ -460,7 +460,11 @@ export default class Reactor { | |||
| break; | |||
| case "refresh-presence": | |||
| const roomId = msg["room-id"]; | |||
| this._setPresencePeers(roomId, msg.data); | |||
| if (msg["edits"]) { | |||
There was a problem hiding this comment.
One issue I realize: what happens to old clients?
As it stands, I think if the client doesn't upgrade their version of the client SDK, they won't be able to handle the new refresh-presence events from the server.
Potential solution:
Clients currently send a versions map when they init:
https://github.com/instantdb/instant/blob/main/client/packages/core/src/Reactor.js#L1056
This would be the first time we use it, but perhaps what we can do is:
- We detect if the client is on a version of Instant > x
- In that case, we start sending the
refresh-presenceevents with edits in them.
a. Aside, perhaps we send different kinds of events too -- something likereset-presenceand 'patch-presence', to keep the paths separate, but I don't feel strongly about this idea
What do you think?
| {:keys [session-ids last-data]} (get-in @room-maps [:rooms room-key])] | ||
| (when (seq session-ids) | ||
| (let [room-data (.get (get-hz-rooms-map) room-key) | ||
| edits (when last-data |
There was a problem hiding this comment.
One rough thought I had:
Is it necessary to derive edits? Perhaps we could broadcast set-presence events similar, to how we broadcast server-broadcast events.
This would mean our resolution would be a bit less granular, but we wouldn't have to do a calculation to derive the edits.
This could be something we layer on down the road though, as am open to either solution.
There was a problem hiding this comment.
Awesome!
Main comment was about handling backwards-compatibility. Rest looks good to me, but deferring to @dwwoelfel's look, as he is the hazelcast expert.
WIP