Result of functional `initialState` of injected slice is not memoized with `rootReducer.selector`

[Mesoptier]

My use case
I need to select the state of a slice that may not have been injected yet (returning either undefined, the initial state, or the current state). To handle the initial state if it has been injected but no action has been fired yet, I use rootReducer.selector (as per https://redux-toolkit.js.org/api/combineSlices#selector). This does indeed return the result of initialState().

The problem
However, initialState() is called again every time the selector is called, causing a new state object to be created every time. This in turn causes useSelector to log the "Selector unknown returned a different result when called with the same parameters." warning.

Desired behavior
I would expect the result of initialState() to be memoized by the library.

Though perhaps I'm overlooking a case where you would want the initial state to be recreated (maybe when the same slice is mounted in multiple stores?). If so, it would be nice to update the documentation for createSlice#initialState to inform the user they might want to memoize the result themselves?

Reproducible case
See this CodePen for the reproducible case:

import {
  combineSlices,
  createSlice,
  configureStore
} from "https://esm.sh/@reduxjs/toolkit";

// Set up simple reducer & store.
const rootReducer = combineSlices();
const store = configureStore({ reducer: rootReducer });

// Build `selectTest` using rootReducer, instead of using injectedTestSlice/withTestSlice,
// so it can be used outside of the code-split slice module (weird use case, I know).
const selectTest = rootReducer.selector((rootState) => rootState.test);

console.log(selectTest(store.getState())); // undefined, as expected

// Set up test slice, with functional `initialState` and incrementing `counter` to highlight
// initial state being recreated.
let counter = 0;
const testSlice = createSlice({
  name: "test",
  initialState: () => ({
    counter: counter++
  })
});

testSlice.injectInto(rootReducer);

console.log(selectTest(store.getState())); // { counter: 2 }, expected { counter: 0 }
console.log(selectTest(store.getState())); // { counter: 3 }, expected { counter: 0 }

[EskiMojo14]

https://redux-toolkit.js.org/api/createSlice#initialstate

This may also be a "lazy initializer" function, which should return an initial state value when called. This will be used whenever the reducer is called with undefined as its state value, and is primarily useful for cases like reading initial state from localStorage.

Open to better wording, but as far as I know it's intentional that initialState is always called fresh when needed. All .selector does is const initialState = reducer(undefined, unknownAction), which in turn is doing (state = getInitialState(), action) => {}.

[Mesoptier]

I see, but that does lead to a logical inconsistency somewhere though, no?

The useSelector hook calls the selector twice with the same parameters and expects the same result both times. But that's impossible to achieve if the combineSlices#selector + createSlice#initialState() combination returns a fresh result each time.

More generally, this causes the state to appear to have changed despite no actions having been fired. Which seems antithetical to Redux fundamentals. (Though I suppose the act of injecting a slice also doesn't fire an action but would be expected to change the state.)

[EskiMojo14]

yeah, the combination of logic seems non-ideal. i reckon we have a couple choices:

• cache getInitialState everywhere, meaning the below would now always be the case:

reducer(undefined, action) === reducer(undefined, action)

• this currently isn't required anywhere, and would be a potential semantic change that somebody might be relying on
• only cache initial state in injected scenarios, meaning combineSlices().selector and createSlice().injectInto().getSelectors() would maintain their own cache
  • this is still a semantic change, but a smaller one

I'm personally leaning towards the second one.

[Mesoptier]

• cache getInitialState everywhere, meaning the below would now always be the case:

  reducer(undefined, action) === reducer(undefined, action)

• this currently isn't required anywhere, and would be a potential semantic change that somebody might be relying on

It also wouldn't match the regular behavior of reducers. Nowhere is it expected that a reducer returns the same result for the same parameters, since that is the place to create new state.

• only cache initial state in injected scenarios, meaning combineSlices().selector and createSlice().injectInto().getSelectors() would maintain their own cache

  • this is still a semantic change, but a smaller one

I'm personally leaning towards the second one.

Agreed that this seems like the most straightforward solution. The issue is specifically with these selector methods—since in other scenarios the initial state would have been injected into the store's state and thus only constructed once­—so that's the place to solve it.

---

Take this with a grain of salt, since I am not familiar with all the design decisions or potential problems: but in my opinion this whole setup of having a "virtual" state (where the initial state is injected) that is only accessible via these specific selectors is a bit unexpected and prone to user error. The replaceReducer approach would fire a dummy action on the store, ensuring that the actual state was updated with the injected reducer's initial state. That seems much more foolproof. Again, this is just an outside perspective, I'm sure there were good reasons for the current mechanism.

[EskiMojo14]

Nowhere is it expected that a reducer returns the same result for the same parameters, since that is the place to create new state.

actually I disagree - reducers being pure and deterministic is one of the core requirements of Redux. with that said, lazy initial state seems to be the one place we're looking past that.

[Mesoptier]

actually I disagree - reducers being pure and deterministic is one of the core requirements of Redux. with that said, lazy initial state seems to be the one place we're looking past that.

What I mean is that it's never expected that a reducer returns the same object reference. I agree that reducers should be pure and deterministic, so the returned state should be deeply equal, but I don't think it has to be shallowly equal.

A simple reducer like this always returns a new array/object instance:

function testReducer(state = [], action: PayloadAction<string[]>): string[] {
    return [...state, ...action.payload];
}

We never have testReducer(undefined, action) === testReducer(undefined, action), but we do have deepEqual(testReducer(undefined, action), testReducer(undefined, action)).

[EskiMojo14]

Redux never does deep equality checks, it always relies on referential equality to know when state has changed.

[Mesoptier]

Redux never does deep equality checks, it always relies on referential equality to know when state has changed.

I understand that, my example was just to show that a reducer does not (necessarily) return the exact same object reference when called with the same parameters twice.

... it should generate a new object containing the necessary changes. ...
— https://redux.js.org/usage/structuring-reducers/prerequisite-concepts

(This is off-topic for this issue, so I'm fine with leaving it there 🙂)

[markerikson]

Yeah, reducers are "pure and deterministic", but that does not mean they return the same reference when called repeatedly. todosReducer(todosState, {type: "todoToggled", payload: 1}) will always return an equivalent result, but it's going to be new references every time. Given that, there's also no requirement that reducer(undefined, anyAction) will return the same initial state reference.

[EskiMojo14]

gotcha, makes sense - in that case the cache at point of selection makes sense.

Take this with a grain of salt, since I am not familiar with all the design decisions or potential problems: but in my opinion this whole setup of having a "virtual" state (where the initial state is injected) that is only accessible via these specific selectors is a bit unexpected and prone to user error. The replaceReducer approach would fire a dummy action on the store, ensuring that the actual state was updated with the injected reducer's initial state. That seems much more foolproof. Again, this is just an outside perspective, I'm sure there were good reasons for the current mechanism.

I can't speak to the specific reasons as this API was designed by @phryneas - I simply did the work in implementing it as specified.

[phryneas]

The replaceReducer approach would fire a dummy action on the store, ensuring that the actual state was updated with the injected reducer's initial state.

That approach had edge-cases where actions were dispatched during render, which caused all kinds of problems, up to crashing React, so we were looking for ways that would avoid that action dispatch specifically.

The way we show it it is set up in a way that your reducer will always be injected before you call a selector - the approach you are picking here that avoids the injection and returns undefined is definitely not "usage as intended" (or documented).

As for the stability, I agree, this is a problem we didn't notice earlier, we should look into that - this is less about executing reducers, but more about "having state", even if it isn't part of the real state yet.

[markerikson]

Should be fixed by #4908 .