We use `export default` begrudgingly here. Ideally we'd use just `export`, though this entire SDK expects things to be exported as a default. Instead of breaking everything, we'll sacrifice our export pattern for a smaller diff - a later commit can always do the default export -> regular export conversion.
Currently, any error in the `GroupStore`s several requests can cause the whole
`GroupView` component to hide and be mark the group as failed to load.
Since it is known that group members may fail to load in some cases, let's only
show failed to load for the whole group when the summary fails.
This also strengthens the `GroupView` test by ensuring we wait for multiple
updates for checking results.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
Take a step closer to a flux-like architecture for group data, for
the purposes of providing features that require it.
Now the app has a single GroupStore that can be poked to fetch
updates for a particular group.
using a FIFO queue.
This is needed in order to lower the priority of getting group
state and prioritise everything else, namely initial sync.
It should be noted that this by no means guarantees that the
first incremental sync will happen sooner; the client could
end up doing some other requests first instead.
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.
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)
2017-10-04 16:56:35 +01:00
Renamed from src/stores/GroupSummaryStore.js (Browse further)
