You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As described in #81, when we implement marking messages as read when you scroll past them, we'll have the unread markers disappear optimistically without waiting for an ack from the server:
Unlike most everything else in the Zulip data model, apply "latency compensation" when marking messages as read on scroll, meaning eagerly apply the change to the local UI rather than wait for the server to acknowledge it with an event.
Specifically, eagerly fade out the unread-message markers in the message list.
This issue is for going further, to eagerly update the model itself.
The zulip-mobile RN app doesn't do this; the consequence is that it looks kind of glitchy as the "N unreads" banner at the top of the message list doesn't update or disappear in sync with the unread markers.
I'm not actually sure what the web app does.
The downside is that if we eagerly update the model, then it's no longer part of a coherent snapshot together with the rest of our model — we'd be giving up some of the consistency provided by the Zulip event system.
There are a couple of approaches we could take to that consistency question, but we should think through the consequences.
When doing this, we should also do the same with the "mark as read" button at the bottom of the message list. As part of that, we'll make its fade-out animation somewhat longer again. See #613.
The text was updated successfully, but these errors were encountered:
As described in #81, when we implement marking messages as read when you scroll past them, we'll have the unread markers disappear optimistically without waiting for an ack from the server:
This issue is for going further, to eagerly update the model itself.
There are a couple of approaches we could take to that consistency question, but we should think through the consequences.
When doing this, we should also do the same with the "mark as read" button at the bottom of the message list. As part of that, we'll make its fade-out animation somewhat longer again. See #613.
The text was updated successfully, but these errors were encountered: