this way we have a flexbox layout in the resizer with:
- the resize handle (fixed)
- the show more/less button, if any (fixed)
- the list of tiles (grabbing whatever is left)
For https://github.com/vector-im/riot-web/issues/14035
**This option is not recommended as it completely obliterates all chances of being able to support someone with a broken room list. It is intended for specific testing scenarios only.**
Known issues:
* Causes scroll jumps when the button gets added to DOM
* Resize handle is invisible when there's a show more button
TODO:
* Clean up comments
* Clean up useless code (all the padding stuff isn't needed)
Previously we were creating a notification state whenever we needed one, which was leading to hundreds of listeners even on a small account. To ease the burden, and reduce the load of having to wake so many listeners, we now record a single listener for each tag ID and room combination.
This commit also introduces a number of utilities to make future notification work a bit of an easier transition, such as the `isX` and `hasX` getters on the new NotificationState abstract class. Similarly, "snapshots" have been added to reduce code duplication between different kinds of states checking for updates.
The ListNotificationState is now heavily tied into the store which offers it to help reuse the cache of room notification states.
Fixes https://github.com/vector-im/riot-web/issues/14370
This is more general maintenance than performance as the RoomList doesn't need to be generating layouts for the sublists, and it certainly doesn't need to be creating a bunch of extra ones.
The sublists are perfectly capable of getting their own layout instance and using it, and we are perfectly able to limit the number of these things we create through the session's lifespan.
In this demonstration, we remove the cutting line (as it collides with the tile in a weird spot) and instead replace the tile with a placeholder when the text is about to collide with the avatar in the tile. We use a `round()` for this because through some amazing coincidence the collision happens at 0.47, which is close enough to 0.5 for people not to notice.
The layout updates are anecdotal based on devtools flagging the values which are "changing" even if they aren't. The scrolling feels better with this as well, though this might be placebo.
We now use offsets and scroll information to determine where the headers should be stuck to, still supporting the transparent background.
Some scroll jumps were originally introduced as part of the change in numbering, so they have been fixed here. By proxy, some additional scroll jump/instability should be fixed as well.
This has a lingering problem of still causing a huge number of no-op UI updates though, which will be dealt with in a future commit.
It should be in all major browsers as of years ago, and we use it unguarded elsewhere in the app. The performance benefits of it appear to be worthwhile enough to keep it, though it's not a perfect solution.
