Expose currentReducer from store through getReducer()
See original GitHub issueThis is not a duplicate of https://github.com/reduxjs/redux/issues/1246 because we have a different type of use case
New Features
I would like to get the currentReducer using the store.getReducer()
What is the new or updated feature that you are suggesting?
The createStore in https://github.com/reduxjs/redux/blob/master/src/createStore.ts will have a new method
function getReducer(): Reducer<S, A> {
return currentReducer as Reducer<S, A>;
}
and get exposed in store object
Why should this feature be included?
Our project uses a closed source proprietary library which initializes the redux context for us. However we would like to override some part of the reducer logic, but we cannot modify the source because we don’t have it or use other libraries to do it.
Since we cannot initialize the reducer by ourselves, we can only resort to extracting the reducer from the store. This is a different situation than https://github.com/reduxjs/redux/issues/1246 as they have the full access of the reducer when passing into createStore. So we would like to add this method to get the currentReducer out, and wrap it to change some behavior, and pass it back to replaceReducer.
What docs changes are needed to explain this?
We will need to modify the Store Methods part of the document to explain the new method https://redux.js.org/api/store#store-methods
Also I can add some of the example code in the documentation to illustrate how to use together with replaceReducer to override some of the reducer logic.
Issue Analytics
- State:
- Created 2 years ago
- Comments:11 (6 by maintainers)
Top GitHub Comments
Hmm. I’m actually a bit confused by this piece of the snippet:
I realize this is effectively pseudocode because
store.getReducer()
doesn’t even exist yet 😃 But there’s a problem with this bit conceptually.The underlying Redux store takes a reducer function. Once that function has been created, there’s no way to figure out how it might have been created in the first place, and what the store itself tracks is a reference to that function.
This snippet is written assuming that the store is tracking an object full of slice reducer functions, which isn’t what it does.
Per the Code Splitting page in the docs, this is why it’s necessary / recommended to keep around an object with the original slice reducers for later reuse, so you can re-create the root reducer using those same slice reducers as the input.
But, there’s no way for
store.getReducer()
to return those slice reducers by itself - the fact that those ever existed is gone by the time the store gets its hands on the root reducer.So, in that sense, I don’t see how having a
store.getReducer()
function helps here for this use case.Something like this would be great for code-splitting. I have been hacking around this afternoon to find a clean way to load a feature slice when a lazy loaded component is routed to. Here’s something I have come up with so far. This specific part of the code could benefit from having
getCurrentReducer
when calledreplaceReducer
. I will try and get an example repo pushed up soon, but here’s a screen shot: