Any performance concerns with creating nested reducers?

[lancemcmuffin]

Hello! My apologies if this has recently been answered elsewhere, but most threads I found on this topic were prior to the release of the React hooks API, so figured a fresh question wouldn't hurt.

Note: unfortunately the code I am working with for this question is large enough and old enough that converting to Redux Toolkit is not an option. So this question assumes the older actions/reducer pattern

I have a code library (call it my-library) that is mostly used for React components, but also exports a number of redux reducers & actions that are common to the group of applications I'm building. The common reducers are combined with app-specific reducers, with the end store result looking something like this (where each piece of state corresponds to one reducer):

{
  myLibraryState1,
  myLibraryState2,
  myLibraryState3,
  thisAppState1,
  thisAppState2,
  thisAppState3,
  thisAppState4
}

The number of reducers both within my-library and in my individual applications has been gradually increasing, so I am thinking it would be helpful to have a store that makes obvious which pieces of state are coming from my-library. In other words, I am considering changing the store to look like:

{
  myLibrary: {
    state1,
    state2,
    state3
  },
  thisAppState1,
  thisAppState2,
  thisAppState3,
  thisAppState4
}

Assuming my selector functions already target the most specific piece of state applicable to a given component, are there any performance impacts I should be aware of if I moved to this structure? It seems like state updates could become more expensive (if, for example, I wanted to set myLibrary.state1.attribute1), but I'm not certain. The reducers within myLibrary are completely disconnected from each other, the only thing they have in common is being defined within my-library, so I want to make sure I understand any potential risks to this approach.

Thanks!

[markerikson]

No, no meaningful perf considerations here - just keep selecting the most specific state possible in components.

As a side note, you can migrate existing code to RTK incrementally, file-by-file, and we strongly recommend at least switching the store setup to RTK's configureStore to get the dev mode checks active in your codebase:

• https://redux.js.org/usage/migrating-to-modern-redux