Room upgrades, direct chats, etc all end up being lost in these scenarios. Instead of losing them to the list, try and put them into a relevant spot of the list.
Fixes https://github.com/vector-im/riot-web/issues/9020
Settings can trigger before we're ready, so don't generate the room list. This also includes a comment to signify to future people that we need to track settings still.
Pretty much cut/pasting it in, as there's not really a whole much to help make the code more understandable here.
This also includes a comment block longer than the code it describes in hopes it explains away the problem of understanding what it does.
Should fix https://github.com/vector-im/riot-web/issues/8861
Fixes https://github.com/vector-im/riot-web/issues/8936
Watchers are now managed by the SettingsStore itself through a global/default watch manager. As per the included documentation, the watch manager dispatches updates to callbacks which are redirected by the SettingsStore for consumer safety.
Previously it made some complicated assumptions about the contexts it was called in (it generally assumed it just had to shuffle rooms between tags and didn't really handle new rooms very well).
The algorithm now eagerly tries to drop rooms from tags and carefully inserts them. The actual insertion logic is mostly untouched: the only part changed is how it handles failure to insert into tag. It shouldn't be possible for this algorithm to completely skip a room unless the tag is empty, so we special case that.
There are several TODO comments to be addressed here. Namely, it doesn't handle manually ordered tags (favourites, custom, etc) and doesn't check if tags are even enabled. Changes in this area are waiting for https://github.com/matrix-org/matrix-react-sdk/pull/2686 to land to take advantage of monitoring the settings flag for tags.
New rooms (joined, invited, created, etc) were being ignored because they matched the check as soon as the iterator hit a non-recents section. This fixes the check to ensure there's a positive ID on the room being in the tag (or not, in the case of new rooms) before lying to the rest of the function.
Additionally, a fix for favourites has been included to stop the list expanding to fill the void - turns out it was inserting the room twice into the list, and this was breaking the tile rendering. The room sublist would allocate space for the tile, but React would prevent the tile from showing up because of duplicate keys.
Fixes https://github.com/vector-im/riot-web/issues/8868
Fixes https://github.com/vector-im/riot-web/issues/8857 correctly
When we load the page, all encrypted events arrive well after we've generated our initial grouping which can cause them to jump to the top of their categories wrongly. For direct chats, this meant that people who don't have a lot of unread messages would see ancient rooms bubbling to the top for no reason after the page has loaded.
We still have to track when the last category change was (ie: when we switched from red -> grey) so that when the category doesn't exist in the list we can insert the room at the right place (the start of the last category when we switch beyond the order expected).
This changes the approach from regenerating every time there's a change to incrementally fixing the room lists. Additionally, this forces the pin options on for people and implements the sticky room behaviour.
Known bugs include newly joined rooms, invites, etc not sorting correctly.
This takes out the old user and room settings, replacing the paths with the new dialog editions. The labs setting has been removed in order to support this change.
In addition to removing the old components outright, some older components which were only used by the settings pages have been removed. The exception is the ColorSettings component as it has a high chance of sticking around in the future.
Styles that were shared by the settings components have been broken out to dedicated sections, making it easier to remove the old styles entirely.
Some stability testing of the app has been performed to ensure the app still works, however given the scope of this change there is a possibility of some broken functionality.
This is intentionally not removing the labs flag or other supporting structures of the old settings to make a revert as easy as possible in the event that needs to happen. All of the cruft left behind (TempTab, temp styles, labs flag, old components, etc) will be removed in the very near future.
`unread` and `unread-muted` store booleans in the cache, and can easily be `false`. Without this patch, both of those cached types would be cleared from the object where a later call to `getRoomState` would try and re-populate them. `getRoomState` is supposed to use the cache where possible to avoid making the more expensive calls required to calculate those booleans.
On my account in a test environment, this brings the `generateRoomLists` execution time down from ~250ms to just ~30ms.
This still does not solve the whole issue, but should solve the more common case of performance woes for people.
the idea is that it will keep a RoomViewStore for every
room on the screen, and also keep track of which one is
the current one.
For now, it just replicates the existing functionality of
having just 1 room on the screen.
Since the RoomViewStore just has access to a local dispatcher
and not the global anymore, all dispatching of actions
needs to be moved to the OpenRoomsStore, so room alias resolving,
event forwarding, ... is moved there.
Currently, any error in the `GroupStore`s several requests can cause the whole
`GroupView` component to hide and be mark the group as failed to load.
Since it is known that group members may fail to load in some cases, let's only
show failed to load for the whole group when the summary fails.
This also strengthens the `GroupView` test by ensuring we wait for multiple
updates for checking results.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
Not doing so results in the RoomListStore tracking stale data when the user reads messages on another device. The visual effect of this is rooms being incorrectly pinned in places they shouldn't be, such as the top of the list. This also fixes another visual bug where rooms don't move down once their timelines are read. This second issue is mot prominent when multiple rooms have been pinned to the top, and the middle one is read ahead of the others - it'll stick around until some other condition decides to wipe the room's cached state.
Fixes https://github.com/vector-im/riot-web/issues/7653
This is more reliable with LL enabled as the syncing user is
only known when it was active in the current timeline
or when the members have been loaded
as everything listens to the dispatcher, dispatching an action can be quite slow,
especially when only matched in one listener, and the rest all having to be called
to just say "no, thanks". This is especially the case for the RoomMember.membership
event being put on the dispatcher, as there can be thousands of these events
when the room members are loading.
Since the RoomMember.membership action is only used on one place,
and only for the syncing user, change it to just that and only dispatch
in that case. This saves 100-300ms when setting the OOB members in
a big room (7000k members)
Maybe later on we can back this by room.getMyMembership() and avoid the
listener even...
Fix Riot's behaviour with room tags after my cleanup in
https://github.com/matrix-org/matrix-doc/pull/1457 . Although, reading
it again, it's not clear how you're supposed to tell the difference
between a reverse-dns tag name and a legacy freeform text tag
(contains a '.'?) - I've left it detecting these as freeform text
for now.
ActiveWidgetStore is now reponsible for removing the current
persistent widget from the store if it's been removed from whatever
room it was in. As per comment, this leaves us with the store updating
itself in this case but in all other cases, views call setters on the
store to update its state. We should make it so the store keeps itself
up to date and views aren't responsible for keeping the store up to date.
The store now emits events so it can notify PersistentApp when it changes.
Fixes https://github.com/vector-im/riot-web/issues/7076
As per https://github.com/matrix-org/matrix-doc/issues/1354
This is whitelisted to only jitsi widgets for now as per comment,
mostly because any widget that we may make always-on-screen we need
to preemptively put in a PersistedElement container, which is
unnecessary for any other widget.
Apologies that this does a bunch of refactoring which could have
been split out separately: I only discovered what needed to be
refactored in the process of doing this.
Fixes https://github.com/vector-im/riot-web/issues/6984
* Show a spinner while we wait for widgets to be deleted
* Hide widgets while they're pending deletion
* Don't put another jitsi widget into the room if there's already
one pending
- implement generic dispatch to close user/room/group settings
- use dispatch to allow clicks on disabled left/right/middle panel to
close settings
A much more maintainable approach would be to use dedicate routing
instead of doing different things depending on what page of the app is
currently being viewed. At the very least we could make the concept of a
settings page generic.
Take a step closer to a flux-like architecture for group data, for
the purposes of providing features that require it.
Now the app has a single GroupStore that can be poked to fetch
updates for a particular group.
using a FIFO queue.
This is needed in order to lower the priority of getting group
state and prioritise everything else, namely initial sync.
It should be noted that this by no means guarantees that the
first incremental sync will happen sooner; the client could
end up doing some other requests first instead.
For each successful request of a group profile, we previously
emitted an `updateGroupProfile` event per caller of
`getGroupProfileCached`. This is sub-optimal because only a single
event emit is required to update the views listening.
It's possible that this was enabling some race to cause a memory
leak but this is not certain, hence the extra logging for future
debugging.
Previously we assumed that a decrypted event has a room_id
but this isn't necessarily true for to_device events.
It makes sense to ignore events that aren't associated with
rooms anyway given that the list we're updating only contains
rooms!
To make sure that we handle rooms that our
client has not seen previously, we regenerate
the room list when the room is stored -
which is indicated by the js-sdk by the
Room event.
so that we can do reorderings of lists ordered by most recent event.
No optimisations here; we only update for timeline events
on live timelines that could update the "unread count".
Actually fixes vector-im/riot-web#6135 unlike #1748, which
incorrectly assumed that custom tags would be included in
listOrders.
This fix makes sure that the `default` case in the `switch`
is actually used.
by sending each tag_ordering with a _storeId and ignoring accout data
that has a matching _storeId.
This will tend to become out of sync with the server over time if
requests continually fail, but subsequent successful requests will
rectify any differences.
This new library handles the simple case of an ordered vertical
(or horizontal) list of items that can be reordered.
It provides animations, handles positioning of items mid-drag
and exposes a much simpler API to react-dnd (with a slight loss
of potential function, but we don't need this flexibility here
anyway).
Apart from this, TagOrderStore had to be changed in a highly
coupled way, but arguably for the better. Instead of being
updated incrementally every time an item is dragged over
another and having a separate "commit" action, the
asyncronous action `moveTag` is used to reposition the tag in
the list and both dispatch an optimistic update and carry out
the request as before. (The MatrixActions.accountData is still
used to indicate a successful reordering of tags).
The view is updated instantly, in an animated way, and this
is handled at the layer "above" React by the DND library.
so that shift-click semantics can work. The store that computes the shift-click
rules has to be aware of the actual order of tags displayed, so they must be done
in the same store.
Also, delete the groupProfilePromise immediately after setting
the group profile (the first if-statement will prevent a new
request from being started).
- Have TagOrderStore listen for MatrixSync actions so that it can initialise
tag ordering state.
- Expose an empty list until the client has done its first sync and has
fetched list of joined groups
This introduces a generic way to register certain events emitted by
the js-sdk as those that should be propagated through as dispatched
actions.
This allows the store to treat the js-sdk as the "Server" in the
Flux data flow model. It also allows for stores to not be aware
specifically of the matrix client if they are only reading from it.
These can be used to dispatch actions immediately, or after some asynchronous
work has been done. Also, create GroupActions.fetchJoinedGroups as an example.
The concept of async action creators can be used in the following cases:
- stores or views that do async work, dispatching based on the results
- actions that have complicated payloads, would make more sense as functions
with documentation that dispatch created actions.
such that:
- it takes a targetTag to be replaced instead the previous tag to insert after
- it optionally displaces the targetTag before or after the inserted tag
This allows for filtering of the RoomList by group. When a group is selected, the room list will show:
- Rooms in the group
- Direct messages with members in the group
A button at the bottom of the TagPanel allows for creating new groups, which will appear in the panel following creation.
Previously, a single user could end up in multiple batches, which would have been fine if the logic didn't assume otherwise. If a request took longer than 200ms, multiple batches would occur with intersecting sets of users, deleting promises that were then assumed to exist.
The logic now takes all "in flight" users to also not be "pending". Pending now means that the user will be processed in the next batch. "In flight" means the user is part of an ongoing batch.
This uses a `ready` flag assigned to each fetching API used by the GroupServer. I've avoided making this generic for now for want of not doing so early.
This will make invalidating the userGroups cache for the user architecturally more sound (the plan is to have GroupStore hit FlairStore as opposed to Flair itself in order to invalidate the cache).
In order to provide feedback when adding a room to a group, the group summarry store needs to be extended to store the list of rooms in a group. This commit is the first step required.
The next step is to get the GroupRoomList listening to updates from GroupStore and expose the list of rooms from GroupStore.
(We're running out of words to describe the hierachy of things that store things)
* Read the new flag in the summary API (the one we were reading
was actually whether the group server listed you as a member to
non-members).
* Remove call to now-dead _loadGroupFromServer andf use the store
instead
- 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
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
After creating a room, display the activity spinner while we wait
for the room to come down the event stream.
This was the intention before but I can't see how it would have
worked: we were setting the 'joining' flag, but then resetting it
by claiming we were already joined in the view_room dispatch.
* Send 'joining' instead of 'joined' in view_room dispatch, which
will set the corresponding joining flag (ie. to indicate we've
sent a request to join the room). Remove the 'joined' flag.
* Reset 'joining' to false otherwise on a view_room dispatch to
prevent it from leaking between rooms (this may have been the
intention of the `if (payload.joined) newState.joining = false`?
Fixes https://github.com/vector-im/riot-web/issues/4701
When clicking on rooms from the room directory. When RoomViewStore
resolved the room alias, it threw away the out-of-band data in the
process. This must have been broken as part of the ILAG /
RoomViewStore stuff.
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.
I thought about adding separate dispatches to prevent confusion but if anyone adds anything that listens to existing dispatches, they really ought to be grep-ing the world for said dispatch actions.
This behaviour was present in the old composer but implemented using local storage. This is unecessary as we don't really care about our drafts across clients, the important thing is that our draft is kept when switching rooms.
As a bonus, ifnore vertical arrow key presses when a modifier key is pressed so that the room switching keys (alt + up/down arrow) don't also cause history browsing (or autocomplete browsing).
Fix for https://github.com/vector-im/riot-web/issues/4224
Due to the way `MatrixChat` does a state update when the `view_room` dispatch fires and a second update when `RoomViewStore` sends an update, the current event ID and room ID were becoming out of sync. The solution devised was to have the event ID managed by the `RoomViewStore` itself and do any defaulting there (for when we revisit a room that we saved scroll state for previously).
This required a few changes:
- The addition of `update_scroll_state` in `RoomViewStore` allows the `RoomView` to save scroll state for a room before swapping to another one. Previously the caching of scroll state was done in `RoomView`.
- The `view_room` dispatch now accepts an `event_id`, which dictates which event is supposed to be scrolled to in the `MessagePanel` when a new room is viewed. It also accepts `event_offset`, but currently, this isn't passed in by a dispatch in the app, but it is clobbered when loading the default position when an `event_id` isn't specified. Finally, `highlighted` was added to distinguish whether the initial event being scrolled to is also highlighted. This flag is also used by `viewRoom` in `MatrixChat` in order to decide whether to `notifyNewScreen` with the specified `event_id`.
