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.
