The current approach to the timeline leads to some complications with how the notifications will work. Considering Evelium is going the route of client-side calculated notifications/unread counts, an accurate timeline with read receipts is needed.
Currently sync data is stored as per #66 however this just blindly takes the timeline from the response and appends it to an array (which is then transferred as-is throughout the app). We probably need some sort of timeline class, like the js-sdk, to handle the representation of the timeline.
Some concerns are:
The limited parameter is ignored
Backfilling isn't a thing yet (#54), and I suspect the data we store isn't suitable enough to do it
The timeline is a thing that needs constant calculation, and we don't do anything about it (redactions, etc all interfere with being able to put events in a nice and easy array)
We don't do any smart limiting of the visible tiles, therefore it's quite easy to end up with thousands of DOM elements for a room.
The timeline limiting code was lost as part of the storage rewrite
This issue is to track the various concerns with how the timeline works and serves to try and figure out how best to treat it.
The current approach to the timeline leads to some complications with how the notifications will work. Considering Evelium is going the route of client-side calculated notifications/unread counts, an accurate timeline with read receipts is needed.
Currently sync data is stored as per #66 however this just blindly takes the timeline from the response and appends it to an array (which is then transferred as-is throughout the app). We probably need some sort of timeline class, like the js-sdk, to handle the representation of the timeline.
Some concerns are:
limitedparameter is ignoredThis issue is to track the various concerns with how the timeline works and serves to try and figure out how best to treat it.