This was for when the new and old versions were available
concurrently on /develop and /app.
The various migration steps are still logged to the console in
js-sdk.
In summary this makes RoomTiles (and RoomAvatars) do more for
themselves in terms of reacting individually to state changes in
the js-sdk.
Instead of force updating the entire room list for avatar changes
and room name changes, do this in the RoomTile and RoomAvatar
instead. This increases the number of listeners listening to the
matrix client, but allows us to properly implement a
shouldComponentUpdate for RoomTile (because the avatar, name and
notification count are now in component state)
by not reusing the same function and invoking separate conditions
to decide what the function does but instead using different
functions.
Also, show the GroupMemberList after inviting a member, otherwise
we might end up looking at the member we were already looking at
instead of the updated list of members.
Whilst testing various DM paths, @lukebarnard1 found that there were
many failures to add the room as a DM against the correct user. It
turned out most of the failures seen were because the user chosen
was the current user. If the user accepted an invite it would often
be marked as with themselves because we chose the sender of the
join event as the DM user.
This fix makes the DM room setting process the same for both the
inviting client and the invited client. A RoomState.members
event causes the DM room state to be set in the room, regardless
of whether we are currently `joining` (see previous impl.)
The two cases for setting a DM are:
- this user accepting an invite with is_direct
- this user inviting someone with is_direct
This should handle all cases for setting DM state.
Otherwise, the DND tile will expect to be within a Droppable,
which is not supported by react-beautiful-dnd. This was causing
errors when receiving an invite.
Fixes#6144
so that they can be dragged and dropped
without interacting with each other, as
they would do if GroupView contained
one droppable to contain them all.
A previous PR (#6134) assumed that the TagPanel feature
would always be enabled, leading to strangeness when it
wasn't: #6136.
(FTR the original layout bug was #6133)
