Events are now decrypted asynchronously, so are not decrypted
at the time of the Room.timeline which is when our RoomList
got the chance to update. It needs to update once the event has
been decrypted.
Ideally we would not update the whole room list order, but this is
how all the room list re-ordering happens right now, so staying
consistent with this.
Fixes https://github.com/vector-im/riot-web/issues/5020
Ignore the update that comes in from the RoomViewStore when the
current room changes or we save our scoll state against the new
room rather than the old one.
Fixes https://github.com/vector-im/riot-web/issues/5010
Introduce a class that consumes updates from the RoomViewStore and
announces to listeners if the active room ID is now or is no longer
the room ID they specified. Naming suggestions welcome: it's
currently called ActiveRoomObserver.
Avoids passing the selectedRoomId down from MatrixChat all the way
through the LeftPanel / RoomList / RoomSubList to the RoomTiles.
Also introduce a CallPreview class that listens directly for
RoomViewStore changes as the call preview in the left panel needs
to know when the room changes, so this allows this component to
update without having to update the entire left panel.
Adding the code code button was done by manipulating the HTML of
the event body to add a span tag, then adding the onclick handler
after the thing was mounted. Apart from splitting the code between
two places, adding the span tag was, according to Chrome's
profiler, taking up quite a lot of CPU cycles (apparently as soon
as you set the innerHTML on a div). Instead, just build the whole
lot together after the component mounts.
Emojione's regex for detecting emoji is *enourmous* and we were
running it on every display name, room name, message etc every time
those components mounted. Add a much simpler regex to rule out the
majority of strings that contain no emoji and fast-path them.
Makes room switching about 10% faster (in my tests with all the
profiling turned on).
...on room switch. We were setting most of the state in viewRoom,
but getting the current room ID from the RoomViewStore, but this
meant we did one setState from the RoomViewStore updating,
re-rendered and then setState again in viewRoom causing another
render. This just sets the room ID in viewRoom.
onHaveRoom sets some more state (among other things) so putting it
in the setState callback so it could observe the new state caused
us to have to re-render again unnecessarily. Just give it the new
state as a parameter.
Calling just checkFill on DidMount did not initially set the
scrollTop which meant that one back pagination request is always
performed regardless. This meant we would end up rending the
first batch of events, then paginating and re-rendering again
after the pagination got another batch, causing unnecessary render
churn.
to keep the place we're scrolled to in rooms. This mainly eleimates
the extra, superfluous onRoomViewStoreUpdate callback that
happened when the previous room saved back its scroll state.
Moving the scroll state to a separate store means we can have this
not emit events because nothing needs to know when the scroll state
changes.
If the js-sdk had a lot of history in memory for a particular room,
riot would paginate all that history into the DOM and render it
when switching to that room (before then removing it all again).
This obviously made switching to that room very slow.
This was caused by the fact that we relied on the setState that
happens in TimelinePanel after the pagination taking effect such
that ScrollPanel sees that it no longer needs to paginate, but
in some situations (as far as I can see, in electron...?) this
setState would not take effect until the pagination stopped
fulfiling requests from memory and hit the network.
Fix: don't resolve the promise returned by the pagination request
until the setState has actually happened.
Use `react-sticky` to implement sticky date separators. This will pin a date separator to the top of the timeline panel when the separator scrolls out of the top of the view.
A known issue of this is that the spinner, which is in line with event tiles in the timeline, will appear to push the stuck date separator down. In reality the first date separator after the spinner is in line with event tiles and is not stuck because the spinner forces the timeline to be scrolled slightly further down than it would be otherwise. But also, date separators in the timeline (not "stuck") have a greater height.
Ideally the date separator would be suppressed whilst back paginating, but this will cause the stuck separator to flicker on and off. This is why the suppression has been removed.
David Baker