In 9969b01c5f we stopped updating the sublist whenever we felt like it, which indirectly froze message previews for room tiles (badges, unread state, etc were unaffected because that is managed by a different store). To fix this, we simply have to listen for changes and perform an update.
In 7b97c3032b we reduced the RoomList updates to just added/removed sublists, but didn't consider that we might also have to handle lengths of those sublists changing enough for us to fix the sticky headers.
Any time we though that the room list had to re-render we were dynamically creating a new addRoomFn, which would signal to the sublist that it needed to re-render.
The only reason we wrap the function from the aesthetics is to provide theoretical tiling/multiaccount support through use of different dispatchers, however considering that's not a reality yet we can just use a default dispatcher when none is supplied.
This cuts the render time in half (from ~448ms to ~200ms on my account) per received event, as we're no longer re-mounting the entire room list and instead just the section(s) we care about.
We don't need columns of divs to equally size themselves, so use easier layout techniques to make the list fit in the container. We have to take a hit with `height:100%`, but the hit is much more insignificant than confusing the layout engine.
The layout engine has a hard time with dynamically-but-statically-sized stuff like `width: 100%; display: flex;`, particularly when it is nested so badly. Overall this should improve performance for the app by not having to re-paint so often.
Fixes https://github.com/vector-im/riot-web/issues/14639
We were taking 0.2ms to handle the registration of a timer per event during startup, even before the app is visible to the user. These timers would be short-circuited too, leading to a bunch of wasted time.
0.2ms isn't a lot of time, but multiplied by thousands of events at startup it's pretty significant.
On my account this reduces the full page spinner time from ~50 seconds to just over 20 seconds.
This means we're abusing the AsyncStoreWithClient to get access to a lifecycle, but overall that seems like a minor crime compared to the time spend abusing the store's state as a map.
With thousands of rooms shown, we can save on average 743ms per preview. The new preview time is 0.12ms on average.
