Fixes https://github.com/vector-im/riot-web/issues/4369
Previously the RoomSubList would filter its list of rooms to verify that the incoming call belongs to it. This causes problems when the sub list is being told some rooms don't exist (ie: the list is filtered). It is trivial for the RoomList to instead track which RoomSubList (tag) it should be handing the call off to so we do that instead now. The RoomSubList trusts that the caller has already filtered it and will render the IncomingCallBox if it has an incoming call.
The initialisation here is done on a timer to allow the DOM
elements to be in place before it's run, so it's possible for an
update to happen ebfore the initialisation. Stop & bail out if
there is no this.stickies.
Fix Riot's behaviour with room tags after my cleanup in
https://github.com/matrix-org/matrix-doc/pull/1457 . Although, reading
it again, it's not clear how you're supposed to tell the difference
between a reverse-dns tag name and a legacy freeform text tag
(contains a '.'?) - I've left it detecting these as freeform text
for now.
Take a step closer to a flux-like architecture for group data, for
the purposes of providing features that require it.
Now the app has a single GroupStore that can be poked to fetch
updates for a particular group.
In summary this makes RoomTiles (and RoomAvatars) do more for
themselves in terms of reacting individually to state changes in
the js-sdk.
Instead of force updating the entire room list for avatar changes
and room name changes, do this in the RoomTile and RoomAvatar
instead. This increases the number of listeners listening to the
matrix client, but allows us to properly implement a
shouldComponentUpdate for RoomTile (because the avatar, name and
notification count are now in component state)
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".
instead of every time we get an update from a GroupStore/otherwise.
This was leading to many setStates and renders at startup when we
receive many group /members /rooms etc. responses.
Also, use the rate limited version of refreshRoomList.
Deselecting all tags is now slightly less performant than selecting a tag
but mostly due to the number of RoomTiles being rendered.
Swapping between different tags (a supposed common use-case) feels much
more spritely!
so that shift-click semantics can work. The store that computes the shift-click
rules has to be aware of the actual order of tags displayed, so they must be done
in the same store.
