Expose currentReducer from store through getReducer()

[smeng9]

This is not a duplicate of #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 #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.

[markerikson]

I'm not quite sure I understand the specific use case you're describing.

When you say "initializes the Redux context for us", do you actually mean a Redux store? As in, the other lib creates the store internally and gives it to you, and thus you never have a chance to see what the reducer is?

[smeng9]

Yes we are not able to see the source code of the reducer. But we would like to override some behavior of the reducer.

[timdorr]

The problem is the reducer is only half the issue there. There may be middleware or enhancers also applied to the store, which can significantly alter its behavior before ever getting to the reducer function.

[smeng9]

That's true, but the store is already created, so we cannot add the enhancer before hand

[markerikson]

I can see at least two potential use cases for having this:

• Wanting to do reducer replacement for code-splitting
• Wanting to wrap the original reducer to add additional behavior

Agreed that this doesn't take middleware into account at all, but then again that's not something you can customize later even if you did make the store originally.

Obviously this is trivial at an implementation level - just return reducer.

I'm always a bit hesitant when it comes to adding things to the public API at this point, but I can't immediately think of any reasons why this would be a bad idea exactly.

[markerikson]

It's worth noting that we actually did have getReducer() once upon a time. By which I mean for the first couple months of Redux's existence :) It was there in 1.0, but removed in 2.0 because React-Redux no longer relied on it:

• https://github.com/reduxjs/redux/releases/tag/v2.0.0
• Find a way to cut getReducer and replaceReducer from the API #350
• Remove getReducer() from Store API #668

[wesleygrimes]

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 called replaceReducer. I will try and get an example repo pushed up soon, but here's a screen shot:

[markerikson]

Hmm. I'm actually a bit confused by this piece of the snippet:

useEffect(() => {
  const existingReducers = store.getCurrentReducer();
  const updatedReducers = {...existingReducers, ...{ [slice.name]: slice.reducer}};
  store.replaceReducer(combineReducers(updatedReducers);
}, [slice, store])

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.

[wesleygrimes]

Thanks for the feedback Mark. I’ll dig back into the code and see if I can find another solution. I’m fairly new to react, been knee deep in Angular/NgRx for years.

[markerikson]

Sure, no problem! :) And feel free to ping me or the other maintainers over in Reactiflux if you'd like to chat in more detail there.

[smeng9]

Thanks for the feedback Mark. I’ll dig back into the code and see if I can find another solution. I’m fairly new to react, been knee deep in Angular/NgRx for years.

@wesleygrimes Yeah you will get the whole reducer function out from the store, and you will need to wrap it as another function. We cannot unpack the current reducer.