After accepting a 3pid invite.
Rather than clear the joining flag when the join request completes,
leave it so the RoomView can see that we're expecting the user to
be joined in the various stages that might go through (waiting for
join request, waiting for room object, waiting for 'joined' member
event). The problem in this case was that we had to wait a bit for
the last one, and there was no bit of state to represent it.
This hopefully also makes the logic somewhat simpler.
Fixes https://github.com/vector-im/riot-web/issues/5041
This code only kicks in if the user was ignored after an event was sent. The homeserver should prevent other events from coming in.
Signed-off-by: Travis Ralston <travpc@gmail.com>
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.
