What’s the canonical way to handle ephemeral state? Let’s take typing indicators as an example, e.g. Bob is typing.... At first I thought Phoenix.Presence would be perfect for this, just add a typing boolean in the metadata along with some debouncing, but then I started second guessing and thought maybe it’s not the best tool for the job. Maybe it’s better to just use Phoenix.PubSub and broadcast_from for ephemeral state. How do you think about this? Is there a good rule of thumb for choosing one vs the other?
1 Like
While both are possible, I’d start with Presence.
Remember to clear the typing flag on blur/timeout/message sent. Presence handles user leaving the page, etc, automatically through the Process lifetime.
2 Likes
The rule of thumb seems to be a matter of state lifetimes. For Phoenix.Presence where the prime example is showing whether someone is “in a lobby” or “editing the same document”, the lifetime of that state is tied to the session/document process. In the case of a typing indicator, I think it could also be a contender for using Presence.
The main difference between PubSubs and Presence is that Presence conveniently holds onto relevant state that new users would need through the presence_state initialization, usually about other users. You want to list all the other users in the document, for example, when a new user joins. And if someone joins a room, you’d likely want to show someone is already typing.
In short I think Phoenix.Presence makes sense when you have long lifetimes of state and the state isn’t rapidly changing or the state is required to make sense of the application when new users join. But if the lifetime is short, or if the state changes a lot, or it’s “non-essential” info, it’s probably better to not store it and instead depend on the event stream to “synchronize” the client. For example, I have an application which shares cursor state/highlighting — because this is so rapidly updated and non-essential, it doesn’t make sense to use Presence for it.
2 Likes
