Redux FAQ: Organizing State

Table of Contents

• Do I have to put all my state into Redux? Should I ever use React's setState()?
• Can I put functions, promises, or other non-serializable items in my store state?
• How do I organize nested or duplicate data in my state?

Organizing State

Do I have to put all my state into Redux? Should I ever use React's setState()?

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)?

There are a number of community packages that implement various approaches for storing per-component state in a Redux store instead, such as redux-ui, redux-component, redux-react-local, and more. It's also possible to apply Redux's principles and concept of reducers to the task of updating local component state as well, along the lines of this.setState( (previousState) => reducer(previousState, someAction)).

Further information

Articles

• You Might Not Need Redux
• Finding state's place with React and Redux
• A Case for setState
• How to handle state in React: the missing FAQ
• Where to Hold React Component Data: state, store, static, and this
• The 5 Types of React Application State

Discussions

• #159: Investigate using Redux for pseudo-local component state
• #1098: Using Redux in reusable React component
• #1287: How to choose between Redux's store and React's state?
• #1385: What are the disadvantages of storing all your state in a single immutable atom?
• Twitter: Should I keep something in React component state?
• Twitter: Using a reducer to update a component
• React Forums: Redux and global state vs local state
• Reddit: "When should I put something into my Redux store?"
• Stack Overflow: Why is state all in one place, even state that isn't global?
• Stack Overflow: Should all component state be kept in Redux store?

Libraries

• Redux Addons Catalog: Component State

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

• #1248: Is it ok and possible to store a react component in a reducer?
• #1279: Have any suggestions for where to put a Map Component in Flux?
• #1390: Component Loading
• #1407: Just sharing a great base class
• #1793: React Elements in Redux State

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. Libraries such as normalizr and redux-orm can provide help and abstractions in managing normalized data.

Further information

Documentation

• Advanced: Async Actions
• Examples: Real World example
• Recipes: Structuring Reducers - Prerequisite Concepts
• Recipes: Structuring Reducers - Normalizing State Shape
• Examples: Tree View

Articles

• High-Performance Redux
• Querying a Redux Store

Discussions

• #316: How to create nested reducers?
• #815: Working with Data Structures
• #946: Best way to update related state fields with split reducers?
• #994: How to cut the boilerplate when updating nested entities?
• #1255: Normalizr usage with nested objects in React/Redux
• #1269: Add tree view example
• #1824: Normalising state and garbage collection
• Twitter: state shape should be normalized
• Stack Overflow: How to handle tree-shaped entities in Redux reducers?
• Stack Overflow: How to optimize small updates to props of nested components in React + Redux?