Saqib Naseeb
Saqib Naseeb

Reputation: 741

React Component State management using redux

So Basically, I came across many articles where they are referring to manage state via flux or redux. I wanted to know that how about UI component having its own state? Is it good practice to let redux manage the Api call and success toast messages etc. but UI components should have their own local state? Kindly someone elaborate what is the best practice in industry?

Upvotes: 1

Views: 197

Answers (3)

Saqib Naseeb
Saqib Naseeb

Reputation: 741

After asking many professionals and industry developers, I came to know that managing state through redux depends on your application scope. but more importantly, If I am working on enterprise Application then the application state must be managed through redux.

Now the question is what should be kept in our redux store. well, you can store almost anything in redux store but better to manage the local state of a component as well. for instance, opening a component Boolean should be managed in local state or any string or header name etc.

Upvotes: 1

Alex Bass
Alex Bass

Reputation: 2422

Good question! The answer is usually "it depends", but there are clear cases when you'd probably prefer to use one over the other.

Use Redux for storing state relevant to the application. E.g. the current page/panel that should be shown. As you mentioned, showing a notification/message - is something that'd make sense to store in redux state, as the alternative would be passing state all over the place, e.g. an error prop bubbling up to your root component which renders the toast message. Using thunk is also a good idea when you're fetching/manipulating data relevant to the whole app, e.g. a list of things that appear in several places.

Use component state for storing state only relevant to the component. That is, if you're filling in a form, it makes sense to store the value of text inputs, checkboxes etc. in your component state (perhaps in conjunction with container and presentational components) as the values at this point aren't relevant to the rest of the application.

Upvotes: 0

vijayst
vijayst

Reputation: 21826

Though the question calls for opinion, I am going to leave my answer. There is no standard best practice regarding this. It boils down to convenience and ground rules of your team, if there are more than one people writing the code.

I use Redux quite a lot. However, I won't refrain from using local state in components.

Form handling like input onChange handlers require local state. It is not performant to use global state for onChange handlers.

Reusable component uses local state. Again, it boils down to whether the reusability is a technical reusability or business reusability. If you are developing a custom scrollbar component, use local state. However, if you are using a comment form which is used everywhere in your application, use global state.

I prefer to have most of the stuff in global state. I use redux thunk as well. In redux thunk, it is possible to access global state within the thunk function. This is quite useful as it avoids the reliance for props / context being passed all around.

I do keep some simple things in local state -- for example, show / hide some stuff. I don't mind waiting for promises to resolve before hiding some stuff using local state.

Overall, the decision to use global state vs local state is primarily based on convenience. There are no standard rules other than what you and your team are comfortable with.

React is a way to declaratively deal with UI. There are some rules of the framework like state, props, context. It is left upto the developer to make the UI declarative and performant based on these primitives. How, a developer does it does not matter as long as the code is maintainable and understood by others.

Upvotes: 1

Related Questions