DEV Community

Azizi Yazit
Azizi Yazit

Posted on

React as State Management Library

State

In the context of User Interface (UI), state is data that hold current information that influences the output of render. Its changed over time.

State is user define, so its not only related to component or UI control.

State management library

State management refers to managing the UI states. As applications grow, this can end up becoming one of the most complex problems in UI development.

State management library provide us ability to store the states and exposing an API for UI components across application to access, add and update the states. Example of state management libraries is React (this is not typo) and Redux.

Redux

Redux attempts to make state mutations predictable by imposing certain restrictions on how and when updates can happen. These restrictions are reflected in the three principles of Redux (Single source of truth, State is read-only and Changes are made with pure functions).

React as state management library

If you're building an application with React, you already have a state management library installed in your application. You don't even need to npm install (or yarn add) it. It costs no extra bytes for your users, it integrates with all React packages on npm, and it's already well documented by the React team. It's React itself.
~ Kent C. Dodds

The question now, did we need Redux?
You can find the answer in React doc

Choosing the right state management library is quiet a critical decision. To choose the best for your scenario require an understanding of the "states"

component state

State thats used in locally.

For example button component that uses its clicked state to show loader and icon (both loader and icon is sub component of button)

The button component can be illustrated here

Component state can be managed easily using useState hook.

module state

State thats used across different components in module scope that they (the components) are invoked.

For example listing module that have table component and pagination component. Table used pagination page selected state to changed its data display.

The listing module can be illustrated here

For managing module states, we can use Context API with useReducer

page state

State thats used across different modules in page scope.

For example login module and sign up module that can be toggled based on user interaction their buttons

The login/sign up module can be illustrated here

React have solid technique to manage state in page called lifting up state

So far we have no issues managing 3 types of states (component, module and page) using JUST React. Left is one more type of state, global state.

global state

User submit username and password (local state) in Login page, the loggedIn state (local state) used to show loader and redirect to Dashboard page with data like userId (global state?) passed along the way. userId used by menu module to get the user role and display menu item based on role provided.

Did the userId can be considered as global state?
No. Because it does not changed over time and it can be passed as prop.

Data like userId and others (same type) have been classified wrongly as global state.

You don’t need Redux if your data never changes. The whole point of it is managing changes.
~ Dan Abramov

When prop-drilling problem can be solved by using React (Context API), the only things I think useful to use Redux is managing global state. But when your application is composition of providers (modules) that have its own reducer managing the states on module scope, it seem we don't need global state. In other word, we don't need Redux anymore.

A lots of info, tips and solution that can be seen here. Peoples who involves in the discussion is the Kent C Dodds, Mark Erikson (Redux maintainer), Brian Lonsdorf and many other great React developers.

Top comments (1)

Collapse
 
vineetit1991 profile image
vineet kumar

Seems we are going to the direction of multiple stores(here I can call state) ? Here I can find the issue of debuggability