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".
Otherwise we risk blocking the dispatches on other work, and they
do not need to be done asynchronously.
This emerged as a bug where the room list appeared empty until
MatrixActions.sync dispatches all occured in one big lump, well
after the sync events being emitted by the js-sdk.
This was changed on /develop to fix an issue where the incorrect
index was being used in a condition to handle literal edge cases
of dragging room tiles to start or end of an ordered sublist.
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.
They are:
1. The existing type of Action, Objects with an `action` type.
1. Asyncronous Actions, functions that accept a `dispatch` argument, which can be used to dispatch Actions asyncronously.
- 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.
