Commit graph

12 commits

Author SHA1 Message Date
Bruno Windels
6d7c983e8e convert (Base)ObservableMap to typescript 2022-03-09 11:33:49 +01:00
RMidhunSuresh
8a169d5ddc Convert sortedIndex.js to ts 2021-11-17 20:28:44 +05:30
Danila Fedorin
3952c3b969 Rename BaseObservableList to TypeScript 2021-09-29 17:46:51 -07:00
Bruno Windels
c6e2607f1f guard against updates emitted while populating during first subscription
This came up now because Timeline uses a MappedList to map PendingEvents
to PendingEventEntries. In the map function, we setup links between
entries to support local echo for relations. When opening a timeline
that has unsent relations, the initial populating of the MappedList
will try to emit an update for the target entry in remoteEntries.
This all happens while the ListView of the timeline is calling subscribe
and all collections in the chain are populating themselves based on
their sources.

This usually entails calling subscribe on the source,
and now you are subscribed, iterate over the source (as you're not
allowed to query an unsubscribed observable collection, as it might not
be populated yet, and even if it did, it wouldn't be guaranteed to be
up to date as events aren't flowing yet).

So in this concrete example, TilesCollection hadn't populated its tiles
yet and when the update to the target of the unsent relation reached
TilesCollection, the tiles array was still null and it crashed.

I thought what would be the best way to fix this and have a solid model
for observable collections to ensure they are always compatible with
each other. I considered splitting up the subscription process in two
steps where you'd first populate the source and then explicitly start
events flowing.

I didn't go with this way because it's really only updates that
make sense to be emitted during setup.
A missed update wouldn't usually bring the collections out of sync
like a missed add or remove would. It would just mean the UI isn't
updated (or any subsequent filtered collections are not updated),
but this should be fine to ignore during setup, as you can rely
on the subscribing collections down the chain picking up the update
while populating. If we ever want to support add or remove events
during setup, we would have to explicitly support them, but for now
they are correct to throw.

So for now, just ignore update events that happen during setup
where needed.
2021-05-27 10:02:05 +02:00
Bruno Windels
00a85697ab add license header in all source files 2020-08-05 18:38:55 +02:00
Bruno Windels
c379caf4c0 remove obsolete ifdef comments 2020-04-20 21:31:27 +02:00
Bruno Windels
001dbefbcf stop using default exports
because it becomes hard to remember where you used them and where not
2020-04-20 21:26:39 +02:00
Bruno Windels
a1e527ccbc first round of fixes after running the app again in the browser! 2019-06-02 00:49:47 +02:00
Bruno Windels
6940e14b18 move sortedIndex out of observable as other code will want to use it too 2019-03-08 20:04:28 +01:00
Bruno Windels
2e362d1bbd fixes and tests for add, remove, move and update 2019-02-26 22:03:16 +01:00
Bruno Windels
290886a5eb fix and test subscription and initial values for sort 2019-02-26 21:13:43 +01:00
Bruno Windels
618c4ffe20 restructure observable collections and fixes for sort, filter and map 2019-02-26 20:48:57 +01:00
Renamed from src/observable/list/SortOperator.js (Browse further)