Should data go in a redux state tree?

Question

I am a bit lost on what to keep in the state tree of Redux.

I saw two conflicting statements on what to store in the state tree(s).

• React doc tell us that only user input should be stored in state trees.

The original list of products is passed in as props, so that's not state. The search text and the checkbox seem to be state since they change over time and can't be computed from anything. And finally, the filtered list of products isn't state because it can be computed by combining the original list of products with the search text and value of the checkbox.

• Redux doc tells us that we often should store UI state and data in the single state tree:

For our todo app, we want to store two different things:

• The currently selected visibility filter;
• The actual list of todos.

You’ll often find that you need to store some data, as well as some UI state**, in the state tree. This is fine, but try to keep the data separate from the UI state.

So React tells that we should not store data (I am talking about data of the todos) and, for me, Redux tells the opposite.

In my understand I would tend on the React side because both React and Redux aims to predict a UI state by storing:

1. all what can't be computed (eg: all human inputs) and are part of the UI:

   • checkbox value
   • input value
   • radio value
   • ...

2. All minimal data that could be use to build a query and send it to the API/database that will return the complete user profil, friends lists, whatever...:

   • user Id
   • creation dates range
   • items Ids
   • ...

For me that excludes all database/API results because:

• that stands on data level
• could be computed by sending the right (and computed by pure reducers) query.

So what is your opinion here?

Nyasaland

It's kind of unclear what exactly you're asking. But if you're rendering a list you can have redux store that array of items. The list of items would start out empty but then you can call your API and update the redux state with the returned list from the API. – Alleen

If you were just using React without Redux, the data would be stored as state in one or more components. You could pass that state to child components through props. With Redux the state lives in one place and is passed into "subscribing" React components as props. – Capitulate

@DanielN added some new explanation in my answer. I see that statement in React doc was about only that example. Because component already received his data via props, that's why it's not state, it doesn't meant that this data not in state of another component (root component) – Edris

Answer 1

React documentation about the View Component state, but Redux documentation about the Application state. So, there is no conflicts between definitions.

If we talk about Redux - you make all your components without state (and transform stateless root component to stateful with help of react-redux's connect function). If you have large response from the server and you show your data with pagination / filters, you can treat your application state as what you see on screen and not put all data in Redux store, only what you need to render (for example, 100 rows to show page and total number of rows to show pagination). There is no restriction for this. The whole data you can put into another place. For example, in another data container in web-worker (I make a full request in web-worker and fetch from there only needed data to display).

---

Added after question edited:

The original list of products is passed in as props, so that's not state.

In that example, the reason why list of products isn't state - it's already in props. It means that the one of parent components have this as state.

Edris

Answer 2

I feel that the problem is that originally Redux was pushed really hard, and some people were so purists, that they argued for separating everything to Redux and re-rendering the whole application on every change. And then we ended up with this response of the creator, which actually only added a confusion, because redux was and still is a de-facto standard for new react applications, and a lot of tutorials assume it.

So, I feel that people are pressured from each side, and often they do some things without real understanding why they should (especially newcomers creating constants, actions and reducers). So, for those who read it, please start without redux, and keep it just in local state (but try to keep in some component like DataContainer). For those who need redux, rule thumb is to put all async data (so all requests go through redux), and data which is needed for independent components. If components obviously located nearby, keep it in a local state and pass as props.

Redux is a very helpful library, but it's power is needed only after you start to have at least several routes, different query options and some complex UI. Before that there is a good chance that you are overengineering (but, of course, if you are sure that you will exceed this size, feel free to start with Redux). And again, you'll literally never will want to put your slider or small dropdown position in the store -- react's state serves perfectly for it.

Chirr