-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[addons-react] aggregating changes from dispatches to avoid multiple setState calls #265
Comments
Redux is able to handle this because there is only one store and any changes that are synchronous are batched into a single We've been playing around with using React's batched update strategy to buffer all 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 |
Thanks for the clarification @mridgway! In that case what's the benefit of having multiple stores vs a single store with multiple reducers ? |
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. |
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.
|
I think #324 could be relevant here. |
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
emitChange
s from the store, thus resulting in multiplesetState
calls for components that are connected to multiple stores usingconnectToStores
.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.
The text was updated successfully, but these errors were encountered: