- Acts as a layer between GroupView and the group APIs that modify the summary individually. This allows for abstraction of getting the new summary once a successful API hit has been done.
- The plan is to also control the avatar, topic, body of the summary via the same class
Not the full list because on HQ that causes your browser to implode.
This should really be a decent paginated list at this point, but this is better
for now.
With the appeareance of a "X" in the top right of each featured item when editing.
NB: No reloading of summary is done after adding/removing a user/room. The plan is to better than threading a callback all the way down.
And update MemberList to use it as such. This means that the parent
only needs to make react elements for the elements that will
actually be rendered, rather than all of them.
In practive this doesn't make a huge difference as making React
elements is fairly fast, but experimentally (with all profiling
turned on), MemberList went from 25ms in the constructor and
81ms in render to 38ms in constructor but sub 1ms render for
Matrix HQ.
This simplifies the implementation of the button but also adjusts the appeareance such that a warning triangle appears in the top-right of button if an error has occured. The error popup will now appear when hovering over the button (with related CSS).
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.
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.
For reasons I don't fully understand, it appears that sometimes the
ReadReceiptMarker has no offsetParent. Rather than dying with an uncaught
exception when that happens (and taking out half of React as well as the /sync
handler), log a warning and suppress the animation.
- this should fix a race where if the 'hangup' arrives hard on the tail of the
Call.incoming, we don't ignore it.
(We still have a problem in that we blip the hangup tone and UI, but that is
arguably a separate problem)
