Not doing so results in the RoomListStore tracking stale data when the user reads messages on another device. The visual effect of this is rooms being incorrectly pinned in places they shouldn't be, such as the top of the list. This also fixes another visual bug where rooms don't move down once their timelines are read. This second issue is mot prominent when multiple rooms have been pinned to the top, and the middle one is read ahead of the others - it'll stick around until some other condition decides to wipe the room's cached state.
Fixes https://github.com/vector-im/riot-web/issues/7653
This is more reliable with LL enabled as the syncing user is
only known when it was active in the current timeline
or when the members have been loaded
as everything listens to the dispatcher, dispatching an action can be quite slow,
especially when only matched in one listener, and the rest all having to be called
to just say "no, thanks". This is especially the case for the RoomMember.membership
event being put on the dispatcher, as there can be thousands of these events
when the room members are loading.
Since the RoomMember.membership action is only used on one place,
and only for the syncing user, change it to just that and only dispatch
in that case. This saves 100-300ms when setting the OOB members in
a big room (7000k members)
Maybe later on we can back this by room.getMyMembership() and avoid the
listener even...
To make sure that we handle rooms that our
client has not seen previously, we regenerate
the room list when the room is stored -
which is indicated by the js-sdk by the
Room event.
so that we can do reorderings of lists ordered by most recent event.
No optimisations here; we only update for timeline events
on live timelines that could update the "unread count".
Otherwise we risk blocking the dispatches on other work, and they
do not need to be done asynchronously.
This emerged as a bug where the room list appeared empty until
MatrixActions.sync dispatches all occured in one big lump, well
after the sync events being emitted by the js-sdk.
- Have TagOrderStore listen for MatrixSync actions so that it can initialise
tag ordering state.
- Expose an empty list until the client has done its first sync and has
fetched list of joined groups
This introduces a generic way to register certain events emitted by
the js-sdk as those that should be propagated through as dispatched
actions.
This allows the store to treat the js-sdk as the "Server" in the
Flux data flow model. It also allows for stores to not be aware
specifically of the matrix client if they are only reading from it.
