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
we have a gap at the start of the timeline, and it is being resolved (via a pagination) right now
we have a gap at the start of the timeline, and it is not being resolved right now
Historically, we've let embedders add UI items to signal that they've reached the start of the timeline or not. However, this creates complications, as the app have to look at the back-pagination status and conclude from there:
lots of back-and-forths across the FFI layer to get this information
the status is triggered async while back-paginated events will be inserted async too, so there can be latency between the time we know we reached the start of the timeline, and the time events will be inserted into the timeline. (Fun race condition: events being inserted after the app decided to show the start item)
#4816 adds support for a virtual TimelineStart item, which is inserted after pagination terminates and we know we've hit the start of the timeline. This way, apps don't have to take care of it anymore.
The next steps would be to add another kind of virtual timeline item for gaps as well:
structGap{/// Whether the gap is being resolved (via a back-pagination) nowresolving:bool,/// The token used for pagination, if any.token:Option<String>,}
The token field will serve to distinguish, in the future, gaps from one another, would we want to display gaps in general.
But even if we don't display gaps in general, we can improve the situation by maintaining the invariant that we always have a virtual timeline item at start:
a Gap { resolving: true } if a back-pagination is ongoing
a Gap { resolving: false } if there's a gap that might result in more events or hitting the timeline start
This may be used also in the context of the focused timeline, where a Gap could be inserted at the bottom/end (i.e. the most recent position) of the timeline, to indicate that there are more events to be forward-paginated.
A room's timeline can be in three states:
Historically, we've let embedders add UI items to signal that they've reached the start of the timeline or not. However, this creates complications, as the app have to look at the back-pagination status and conclude from there:
#4816 adds support for a virtual
TimelineStart
item, which is inserted after pagination terminates and we know we've hit the start of the timeline. This way, apps don't have to take care of it anymore.The next steps would be to add another kind of virtual timeline item for gaps as well:
The
token
field will serve to distinguish, in the future, gaps from one another, would we want to display gaps in general.But even if we don't display gaps in general, we can improve the situation by maintaining the invariant that we always have a virtual timeline item at start:
TimelineStart
introduced in feat(timeline): add a virtual start of timeline item #4816,Gap { resolving: true }
if a back-pagination is ongoingGap { resolving: false }
if there's a gap that might result in more events or hitting the timeline startThis may be used also in the context of the focused timeline, where a
Gap
could be inserted at the bottom/end (i.e. the most recent position) of the timeline, to indicate that there are more events to be forward-paginated.Rough plan
The text was updated successfully, but these errors were encountered: