Skip to main content

Organizing State

Redux FAQ: Organizing State​

Do I have to put all my state into Redux? Should I ever use React's useState or useReducer?​

There is no “right” answer for this. Some users prefer to keep every single piece of data in Redux, to maintain a fully serializable and controlled version of their application at all times. Others prefer to keep non-critical or UI state, such as “is this dropdown currently open”, inside a component's internal state.

Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it.

Some common rules of thumb for determining what kind of data should be put into Redux:

  • Do other parts of the application care about this data?
  • Do you need to be able to create further derived data based on this original data?
  • Is the same data being used to drive multiple components?
  • Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)?
  • Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
  • Do you want to keep this data consistent while hot-reloading UI components (which may lose their internal state when swapped)?

Further information​

Articles

Discussions

Can I put functions, promises, or other non-serializable items in my store state?​

It is highly recommended that you only put plain serializable objects, arrays, and primitives into your store. It's technically possible to insert non-serializable items into the store, but doing so can break the ability to persist and rehydrate the contents of a store, as well as interfere with time-travel debugging.

If you are okay with things like persistence and time-travel debugging potentially not working as intended, then you are totally welcome to put non-serializable items into your Redux store. Ultimately, it's your application, and how you implement it is up to you. As with many other things about Redux, just be sure you understand what tradeoffs are involved.

Further information​

Discussions

How do I organize nested or duplicate data in my state?​

Data with IDs, nesting, or relationships should generally be stored in a “normalized” fashion: each object should be stored once, keyed by ID, and other objects that reference it should only store the ID rather than a copy of the entire object. It may help to think of parts of your store as a database, with individual “tables” per item type.

For most applications, use Redux Toolkit's createEntityAdapter to manage normalized collections in your slices. It uses an { ids, entities } state structure and provides reducer functions to add, update, and remove items, along with selectors to read them.

The adapter does not turn nested objects into separate entities or replace relationships with IDs. If your API returns nested data, transform it into the normalized shape before adding it to the store. See Normalizing Nested Data for more on this step and tools such as Normalizr.

Further information​

Documentation

Articles

Discussions

Should I put form state or other UI state in my store?​

The same rules of thumb for deciding what should go in the Redux store apply for this question as well.

Based on those rules of thumb, most form state doesn't need to go into Redux, as it's probably not being shared between components. However, that decision is always going to be specific to you and your application. You might choose to keep some form state in Redux because you are editing data that came from the store originally, or because you do need to see the work-in-progress values reflected in other components elsewhere in the application. On the other hand, it may be a lot simpler to keep the form state local to the component, and only dispatch an action to put the data in the store once the user is done with the form.

Based on this, in most cases you probably don't need a Redux-based form management library either. We suggest trying these approaches, in this order:

  • Even if the data is coming from the Redux store, start by writing your form logic by hand with useState. It's likely this is all you'll need. (See Gosha Arinich's posts on working with forms in React for some excellent guidance on this.)
  • If you decide that writing forms "manually" is too difficult, try a React-based form library like React Hook Form or TanStack Form. These keep the form state in the component and give you validation and submission handling. When the user submits, dispatch one action (or call an RTK Query mutation) with the final values.
  • Redux-based form libraries such as Redux-Form and React-Redux-Form are no longer actively maintained, and we don't recommend starting new projects with them. If you truly need form values in the store while the user is typing, write a small slice for that form and update it from the component's change handlers.

If you are keeping form state in Redux, you should take some time to consider performance characteristics. Dispatching an action on every keystroke of a text input probably isn't worthwhile, and you may want to look into ways to buffer keystrokes to keep changes local before dispatching. As always, take some time to analyze the overall performance needs of your own application.

Other kinds of UI state follow these rules of thumb as well. The classic example is tracking an isDropdownOpen flag. In most situations, the rest of the app doesn't care about this, so in most cases it should stay in component state. However, depending on your application, it may make sense to use Redux to manage dialogs and other popups, tabs, expanding panels, and so on.

Further Information​

Documentation

Articles