comparing "Lifting state up" vs Redux,Flux state management

Question

I understood React lifting-state-up "https://reactjs.org/docs/lifting-state-up.html". By this method a developer needs to pass the state functions in parents as props to child. After which I did a couple of session on redux. But, I am unable to understand the main differences in lifting state up vs Redux, flux state management in simple comparisons.

1. Does it mean inside a big web applications "lifting state up" should not be used and redux/flux becomes inevitable
2. Redux simplifies the whole process of state management, but is there any advantage other than abstraction and simplification.
3. By using Redux we will have a single source of truth as compared to "Lifting state up" where we need to keep state in multiple components and thus adding complexity to overall code. In lifting-state-up you can have a single source of truth the only shortcoming of that approach would be your parent component would be cluttered with many states.
4. Is there a performance angle between redux and lifting state up
5. If React is said to be a view library should it had given a state management option in the first place?

Answer 1

Does it mean inside a big web applications "lifting state up" should not be used and redux/flux becomes inevitable

Absolutely not, you need to be use redux/flux, only when the data being used by your app is shared between a large number of components who do not share a close enough parent and that the data keeps on changing and the view needs to be refreshed.

In case when the data is being shared in a small section of your App, you might consider using Context-API for this purpose too.

Redux simplifies the whole process of state management, but is there any advantage other than abstraction and simplification.

Yes, redux offers a wide range of advantages

• Persist state to a local storage and then boot up from it, out of the box.

• Pre-fill state on the server, send it to the client in HTML, and boot up from it, out of the box.

• Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers can replay them to reproduce the errors.

• Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written.

By using Redux we will have a single source of truth as compared to "Lifting state up" where we need to keep state in multiple components and thus adding complexity to overall code. In lifting-state-up you can have a single source of truth the only shortcoming of that approach would be your parent component would be cluttered with many states.

As I said earlier, if the data if shared between components that do not have very direct common ancestor, you might prefer Redux. Redux also offers an advantage that it implements a connect as a PureComponent and hence state updates only affect the components that are using them and will not cause a re-render for other components which don't use those particular states as props.

With Lifting state up, you need to pass down the values all the way down though each and every component and then you need to make sure that the intermediate components are Pure.

Is there a performance angle between redux and lifting state up

The performance issue comes into picture when you are passing state down and don't use PureComponents, causing unnecessary re-renders. Redux is helpful here

Answer 2

Redux is merely an abstraction, it does not give any performance optimisation that you cannot achieve on your own.

However, to achieve the performance optimisation that Redux offers out of box, you need to do a lot of work, such as implementing shouldComponentUpdate for almost every component.

As an example, if some components need to share a common state, the state must be lifted up to a common parent among the components. Every other components in between the parent and those components that don't use the shared state will need to ignore prop changes related to that state through shouldComponentUpdate.

Every component would also need to implement shouldComponentUpdate/PureComponent to check if its props changed, otherwise all child components will be automatically re-rendered when the parent re-renders.

Redux also offers several other convenience features:

• Not having to pass callbacks and props through deeply nested components
• Redux DevTools for visualising state changes, time travelling debugging etc
• Straightforward persistence of state to localStorage through redux-persist
• The use of action creators/thunks, presentational/container pattern etc increases code reusability, testability and maintainability.

Answer 3

There are some great answers here already. I'll take a more pragmatic approach :

Redux provides a single source of truth for all your state, though it can become disparate as you split your reducers.

Component state means application state is naturally more disparate, but portions will centralize through lifting up state as you have mentioned.

The way you manage state in a project will evolve over time. The way you manage your state should also be guided by the application you are writing.

Note also that Redux and lifting up state are not at all mutually exclusive techniques - you can appropriately use both.

For new projects I weigh the convenience of having all the state in one location (single source of truth) vs the inconvenient overhead of having to write actions and connect components.

If in doubt, I would suggest starting with component state, lift it one-two layers, and beyond that I would lift it to a redux store and connect my components directly. This exposes you to the benefits of both approaches in a pragmatic manner.

The tooling and singleton nature of a centralized redux store mean getting various features for free (persistence, time travel, redux devtools etc). On the other hand, I can waste a fair amount of time wiring up an application with redux in early days and lose sight more easily of what I was sitting down to write.

Answer 4

1. Local states and usage of Redux both can peacefully coexist :) i.e. they are not mutually exclusive.
2. Code maintainability wise lifting state up could be very messy in case of the large application. Redux provides a neater solution.
3. Finally, directly from the horse's mouth - An article by the co-author of Redux - You might not need redux https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367

Thus in my opinion you must first try to develop a react application (of medium complexity) without Redux. Use the "Lifting state up" concept. At some point in the course of the development you would intuitively realize that having the state management library like Redux would make life much easier. Sometimes it's better to learn it the hard way. Moving to Redux when it's absolutely necessary will make you appreciate it more.

Answer 5

To answer some of your questions:

1. Does it mean inside a big web applications "lifting state up" should not be used and redux/flux becomes inevitable.

No. Lifting state up is still the preferred thing to do first. You need not put everything into the global store even if you already have it in your project. A lot of state will still be local to some components and that is where it should be kept. Also read When should I use redux.

3. By using Redux we will have a single source of truth as compared to "Lifting state up" where we need to keep state in multiple components and thus adding complexity to overall code. In lifting-state-up you can have a single source of truth the only shortcoming of that approach would be your parent component would be cluttered with many states.

If that is the case you did not apply the principle of lifting state up correctly. The component that has the state should still be the single source of truth. If not, you did not lift it up enough.

4. Is there a performance angle between redux and lifting state up.

Yes. Especially if done wrong. Remember that your mapStateToProps is called for every state change. If you do not pay attention you will do a lot of unnecessary calculations. You can overcome part of that by using selectors.