forked from mystiq/hydrogen-web
adjust fragments status, also add future perf optimization notes
This commit is contained in:
parent
1b228b0200
commit
765a68c766
1 changed files with 11 additions and 7 deletions
|
@ -19,15 +19,15 @@
|
||||||
- adapt persister
|
- adapt persister
|
||||||
- DONE: persist fragments in /sync
|
- DONE: persist fragments in /sync
|
||||||
- DONE: fill gaps / fragment filling
|
- DONE: fill gaps / fragment filling
|
||||||
- load n items before and after key,
|
- DONE: load n items before and after key,
|
||||||
- need to add fragments as we come across boundaries
|
- DONE: need to add fragments as we come across boundaries
|
||||||
- also cache fragments? not for now ...
|
- DONE: also cache fragments? not for now ...
|
||||||
- not doing any of the above, just reloading and rebuilding for now
|
- DONE: not doing any of the above, just reloading and rebuilding for now
|
||||||
|
|
||||||
- adapt Timeline
|
- DONE: adapt Timeline
|
||||||
- turn ObservableArray into ObservableSortedArray
|
- DONE: turn ObservableArray into ObservableSortedArray
|
||||||
- upsert already sorted sections
|
- upsert already sorted sections
|
||||||
- upsert single entry
|
- DONE: upsert single entry
|
||||||
- adapt TilesCollection & Tile to entry changes
|
- adapt TilesCollection & Tile to entry changes
|
||||||
|
|
||||||
- add live fragment id optimization if we haven't done so already
|
- add live fragment id optimization if we haven't done so already
|
||||||
|
@ -35,6 +35,10 @@
|
||||||
- could do this by only loading all fragments into index when filling gaps, backpaginating, ... and on persister load only load the last fragment. This wouldn't even need a FragmentIndex?
|
- could do this by only loading all fragments into index when filling gaps, backpaginating, ... and on persister load only load the last fragment. This wouldn't even need a FragmentIndex?
|
||||||
|
|
||||||
|
|
||||||
|
implement SortedArray::setManySorted in a performant manner
|
||||||
|
implement FragmentIdComparator::add in a performant manner
|
||||||
|
there is some duplication (also in memory) between SortedArray and TilesCollection. Both keep a sorted list based on fragmentId/eventIndex... TilesCollection doesn't use the index in the event handlers at all. we could allow timeline to export a structure that just emits "these entries are a thing (now)" and not have to go through sorting twice. Timeline would have to keep track of the earliest key so it can use it in loadAtTop, but that should be easy. Hmmm. also, Timeline might want to be in charge of unloading parts of the loaded timeline, and for that it would need to know the order of entries. So maybe not ... we'll see.
|
||||||
|
|
||||||
so a gap is two connected fragments where either the first fragment has a nextToken and/or the second fragment has a previousToken. It can be both, so we can have a gap where you can fill in from the top, from the bottom (like when limited sync) or both.
|
so a gap is two connected fragments where either the first fragment has a nextToken and/or the second fragment has a previousToken. It can be both, so we can have a gap where you can fill in from the top, from the bottom (like when limited sync) or both.
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue