CODEWITHSUNDEEP
reactjsredux
Jacob Mason
Jacob Mason

Reputation: 1395

In Redux, should global state replace component state?

My question is, should I still be using stateful React components or should I move that state into the Redux store?

Upvotes: 1

Views: 1114

Answers (2)

Cymen
Cymen

Reputation: 14419

I recommend reading this Medium post: Presentational and Container Components. It outlines the ideas of using component state for UI state but non-UI state is global (redux). It also suggest a pattern of how to approach that by having container components responsible for managing access to the global state and simple view components that the container passes state to as a prop.

So the answer is a little more complicated in my opinion because there are different types of state.

I highly recommend this free video series that goes into Redux in depth and provides a lot of explanation to build your knowledge up quickly: Getting Started with Redux.

After digging into Redux more and using it on a project to learn, I found myself making use of it to store UI state. The particular use case was a long scrolling div. I wanted the scroll position of the div to be the same when the back button was used. It was super easy to hook the click up to a dispatch to update the state for the current div.scrollTop and then on componentMount (back button pressed, component remounts) simply set the div.scrollTop to the position from state.

So I think it can be very useful to have UI state in Redux too. It is easier to reason about and simple to do. I can see building very powerful UIs this way that do not exhibit the typical UI issues seen with single page applications.

Upvotes: 2

koorchik
koorchik

Reputation: 1696

There is no single true answer for you question.

You have different types of states. You have a state of your models (in terms of MVC) and UI (View) state. In classical MVC your models should not depend on UI. So, here we have a question: is it ok to save UI state (inputs, checkboxes state) in global redux store.

The most general rule, in this case, is to use common sense :). You can choose any of the approaches depending on your needs and it will be ok if it suits better for your situation.

But, let's look at several examples.

global redux store for everything

I know apps, that save whole UI state in global redux store. I mean that every keystroke in any field will fire event and will update the global store.

Pros:

  1. It is easy to track state changes when the whole state is in one place.
  2. You can serialize the whole state for debugging purposes. It can be automatic state saving on errors. Or QA engineer can dump UI state with a special keyboard shortcut and send to developers. Developers can take this serialized state and restore whole UI as it was on QA's machine.

Cons:

  1. Rerender the whole app on every keystroke.
  2. A lot of intermediary state (in global store) that is needed only while user entering some data.
  3. Passing state down to your components. You will use "Container" components for this but the question is should your "Container" components be only top-level components or you should wrap leaf dump components in containers. Both variants are acceptable but in most cases it is better to move state higher (while it makes sense). Read about "Smart vs Dumb" components or "Containers vs Presentational components"
  4. You should manage different types of state (from different sources) in one global store.

UI state in your components.

For example, you have a form. And your form manages the state on your inputs by its own. So you just render it as <Form onSubmit={ (fields) => saveFields(fields) }>

Pros:

  1. Intermidate form state is private to form. You can think that this state does not exist at all, it does not matter for you.
  2. The shape of private state is much easier to change.
  3. Components are more coherent. They are more independent, like simple mini applications inside your larger application.

Cons:

  1. Other components cannot access this state.
  2. There is no single place of storing state.
  3. Different appoaches to state management.
  4. Increases possibilty of situations when there will be more than one source of thruth.

Additional resources:

Some general ideas that can be useful:

  1. Handle as less state as possible in your components but not less than required. Stateless components are easier to work with. But remeber that the state will be moved somewhere, so you will need to handle it in any case (it can be store, or presentational wrapper component etc).
  2. Make your components as much independent as possible. You can make good independent components with private state or make them stateless.
  3. Split components into presentational components (context independent) and container components (context dependent).
  4. Move state as high as possible. Prefer saving state in upper level components. It can be not only container components. You can create presentational components that wraps you stateless components just to manage state (they will have no connection to redux)

Upvotes: 5

Related Questions