Refactor the search stuff in RoomView
* factor out the call to MatrixClient.search to a separate _getSearchBatch (so
that we can reuse it for paginated results in a bit)
* Don't group cross-room searches by room - just display them in timeline
order.
* factor out the call to MatrixClient.search to a separate _getSearchBatch (so
that we can reuse it for paginated results in a bit)
* Don't group cross-room searches by room - just display them in timeline
order.
This is preferable to doing the way other QPs are passed (secret, etc) because
the link in the email wants to look like "#/room/<room_id_or_alias>" for guest
read-access (only bouncing you to /login if that room is not readable by guests).
This is hard to do in the current arch because we don't preserve QPs on /room
paths, and we do conditional executions depending on if it is a room ID or
alias. Rather than threading through the email in each section and creating
a fragile mess, just pass the *starting* set of query parameters through to
MatrixChat which can then do the Right Thing when the time comes.
Remove an optimisation which tried to avoid recalculating the scroll on every
render. The problem is that sometimes, when new events, the number of event
tiles remains the same, but we still need to do a scroll, because the height of
the message list changes.
The optimisation was a bit of a waste of time anyway - the actual render will
always be much more difficult than recalculating the scroll position.
Call /forget when the forget button is clicked. Number of shortcomings:
- We need to lazy load the historical list (atm we never get the list of left
rooms; things only go into that list if you leave the room whilst running)
- Once a room is forgotten we need to physically nuke it from the JS SDK.
- Need icon for forget room.
Because invites do not have RoomMembers because we don't have an m.room.member
event for them, just a user ID, and we want to detect conf users at invite
time.
