forked from mystiq/hydrogen-web
update todo lists
This commit is contained in:
parent
0524f06722
commit
c838edb6c4
2 changed files with 8 additions and 0 deletions
|
@ -34,11 +34,14 @@
|
||||||
- lets try to not have to have the fragmentindex in memory if the timeline isn't loaded
|
- lets try to not have to have the fragmentindex in memory if the timeline isn't loaded
|
||||||
- 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?
|
||||||
|
|
||||||
|
# Leftover items
|
||||||
|
|
||||||
implement SortedArray::setManySorted in a performant manner
|
implement SortedArray::setManySorted in a performant manner
|
||||||
implement FragmentIdComparator::add 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.
|
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.
|
||||||
|
|
||||||
|
check: do /sync events not have a room_id and /messages do???
|
||||||
|
|
||||||
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.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -25,6 +25,11 @@
|
||||||
- DONE: support timeline
|
- DONE: support timeline
|
||||||
- DONE: clicking on a room list, you see messages (userId -> body)
|
- DONE: clicking on a room list, you see messages (userId -> body)
|
||||||
- DONE: style minimal UI
|
- DONE: style minimal UI
|
||||||
|
- DONE: implement gap filling and fragments (see FRAGMENTS.md)
|
||||||
|
- allow collection items (especially tiles) to self-update
|
||||||
|
- improve fragmentidcomparer::add
|
||||||
|
- send messages
|
||||||
|
- better UI
|
||||||
- fix MappedMap update mechanism
|
- fix MappedMap update mechanism
|
||||||
- see if in BaseObservableMap we need to change ...params
|
- see if in BaseObservableMap we need to change ...params
|
||||||
- put sync button and status label inside SessionView
|
- put sync button and status label inside SessionView
|
||||||
|
|
Loading…
Reference in a new issue