[addons-react] aggregating changes from dispatches to avoid multiple setState calls

[geekyme]

I have the use case where I receive a large payload from the server in one service call, and would like to dispatch multiple actions after receiving the data (ACTION_ONE, ACTION_TWO, ACTION_THREE) so different store entities will receive the payload.

However, it is not possible to do this without triggering multiple emitChanges from the store, thus resulting in multiple setState calls for components that are connected to multiple stores using connectToStores.

Probably something I'm looking at is a dispatchMultiple function, that can dispatch multiple actions but only ensure a single emitChange. This way we can control when we want multiple emitChanges (using multiple dispatch), or a single emitChange (using one dispatchMultiple). The alternative is of course to dispatch one action only with all the payload to multiple stores and use batchUpdatePlugin but that may be impractical in some cases.

Redux has a nice way of handling this sort of scenario using middlewares.

[mridgway]

Redux is able to handle this because there is only one store and any changes that are synchronous are batched into a single change event. The batchedUpdatePlugin should solve this in Fluxible for any emitChanges in the same dispatch, but not multiple dispatches. It would be difficult to do this across dispatches since they would typically be done in multiple action creators which are asynchronous. I don't think Redux solves the use case of asynchronous action creators that dispatch multiple actions (for instance NAVIGATE_START followed later by NAVIGATE_SUCCESS).

We've been playing around with using React's batched update strategy to buffer all setState calls between two dispatches, but it feels a little hacky.

I've been thinking about proxying the store listeners through some central hub that would be able to create transactions between two different dispatch events. I think you could even use connectToStores as the abstraction that could manage subscriptions using context. It would be interesting to play around with but I'm not sure that I have the time right now.

[geekyme]

Thanks for the clarification @mridgway! In that case what's the benefit of having multiple stores vs a single store with multiple reducers ?

[mridgway]

That's a question I've been asking myself recently. I think in a lot of our use cases we have sections of the page that require data that is completely unrelated to the rest of the page and requires a separate domain of knowledge. In these cases, it's useful to be able to completely separate them rather than have a root reducer that has to deal with calling the correct reducer for different knowledge domains.

By having this separation, we've been able to create a plug-and-play system that allows adding components and stores via npm without having to update a root store/reducer to make sure it receives the correct data. Instead we just need to execute the new action and the store will be populated.

In a larger application, I could also see the single root reducer model breaking down as well since it would continuously get larger and larger without a way to code split. With multiple stores, we're able to load and register stores on the client on demand as they are needed.

I've been thinking about whether Redux's model works only with a single store. It seems like it shouldn't be dependent on that, but the way middleware and dispatching works, you are forced into have only one.

I think there are benefits to both ways but I'd love to hear how others have fared with single vs. multiple stores.

[geekyme]

Thanks for your thoughts Michael. Those are real concerns.

This article http://www.code-experience.com/problems-with-flux/ discusses a better way to structure reducers and store.

On 23 Sep 2015, at 4:49 AM, Michael Ridgway notifications@github.com wrote:

That's a question I've been asking myself recently. I think in a lot of our use cases we have sections of the page that require data that is completely unrelated to the rest of the page and requires a separate domain of knowledge. In these cases, it's useful to be able to completely separate them rather than have a root reducer that has to deal with calling the correct reducer for different knowledge domains.

By having this separation, we've been able to create a plug-and-play system that allows adding components and stores via npm without having to update a root store/reducer to make sure it receives the correct data. Instead we just need to execute the new action and the store will be populated.

In a larger application, I could also see the single root reducer model breaking down as well since it would continuously get larger and larger without a way to code split. With multiple stores, we're able to load and register stores on the client on demand as they are needed.

I've been thinking about whether Redux's model works only with a single store. It seems like it shouldn't be dependent on that, but the way middleware and dispatching works, you are forced into have only one.

I think there are benefits to both ways but I'd love to hear how others have fared with single vs. multiple stores.

—
Reply to this email directly or view it on GitHub.

[mridgway]

I think #324 could be relevant here.