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
