4.0.5 fork

[MosheZemah]

Allow configure the store to notify listeners (store's subscribers) only once per frame and not on every dispatch.
For example let say I have 10 dispatches on the same frame (i.e. one function that calls 5 dispatches and each one of them calls another dispatch). Instead of running the listener on every dispatch, I want to be able to run them only once after all dispatches are over (for performance).

[markerikson]

Appreciate the PR, but there's no need to modify the core for this. Multiple addons already offer this functionality, like redux-batched-subscribe and redux-batch. You can also use the React-Redux batch() API to help with this:

https://redux.js.org/faq/performance#how-can-i-reduce-the-number-of-store-update-events

https://react-redux.js.org/api/batch

[netlify]

Deploy preview for redux-docs ready!

Built with commit 43dbc6f

https://deploy-preview-3836--redux-docs.netlify.app

[MosheZemah]

Hi @markerikson , thanks for your quick response. Using the addons you've mentioned can I skip calling the listeners completely? Do I need to do it on every place explicitly in the code?
My solution offer doing it globally for all dispatches. Is this something I can accomplish with the addons?
Thanks!

[markerikson]

Store enhancers like redux-batch and redux-batched-subscribe wrap the store at creation time, so they apply globally.

The React-Redux batch() API is something you would use yourself in specific locations, such as dispatching multiple actions as a result of an async thunk call.

[MosheZemah]

Hey @markerikson, I looked at the redux_batched_subscribe as you suggested. It seems like they override the internal logic (subscribe) of redux, and it seems like they've copied from an old branch of redux. It also means that if I'll use their package, I no longer receive updates of the logic of subscribe/unsubscribe if you change it in the future. (i.e. they are missing the memory cleanup that was made in 4.0.5 after unsubscribe.
It was better if redux has an API instead of overriding internal logic.

Maybe we should have an option to pass a middleware that will wrap notify subscribers.
My PR allow users to continue get updates from the redux package without overriding any internal logic.

[markerikson]

The point of the enhancer API is to allow addons to override and provide their own implementations of the core store API ({dispatch, subscribe, getState, replaceReducer}):

https://blog.isquaredsoftware.com/2017/09/presentation-might-need-redux-ecosystem/

That contract does not let enhancers see the internals of the existing APIs from the lower-level store being wrapped.

In addition, the actual store implementation knows nothing about "frames". The core store.dispatch contract is that it sequentially calls all subscribers, synchronously.

We're not modifying the core store implementation for this use case.

Given how rarely the store API actually changes, I don't see a need to try to provide an override point just for enhancers to pick up any hypothetical future tweaks to the dispatching logic. That's especially true since the point of an enhancer is that it's going to provide its own implementation of dispatch or subscribe, without needing to know anything about how the lower API is implemented.

The addons I've linked already allow you to solve your use case, in varying ways. You should probably also read my post A Comparison of Redux Batching Techniques, which discusses when it might make sense to use each of those approaches.

For reference, there were some discussions back in 2016-ish about hypothetical modifications to the enhancer definition to allow splitting that logic into smaller overridable pieces, but those PRs stalled and we eventually closed them due to lack of progress and lack of actual interest. See these prior issues/PRs:

• Proof of Concept: Enhancer Overhaul #1702
• Alternate Proof of Concept: Enhancer Overhaul #2214
• Proof of concept: fully create store before dispatching init action. #1576
• Expose notifyListeners in the store API #3180