Okay I am using redux for state management in my react app. Now the question I have is, would it be all right to use useState knowing that I would only be using that state in one component only( i.e. the component that it was created in). It doesn't need to be passed, to other components(not even its children). So can I use useState in between of redux? I need to use redux btw.
You should use local state i.e. useState as much as possible. Redux state should be the last resort. Only use Redux state if you absolutely need to pass data from one end of the application all the way to another end. This is both good practice for tight coupling and good performance.
Yes, for sure. There's no reason to use your Redux state for local state.
Related
Is it still possible to render variables in react? Trying to use a more lightweight method of storing data on a component, but variables don't seem to render anymore in react. Is useRef the new method for variables or is it still possible in basic let variables.
Here is an example of variables not rendering in react:
https://codesandbox.io/s/serene-galileo-ml3f0?fontsize=14
You have a misconception about how React handles state. The reason why normal variables don't seem to work in React is actually an optimization. React only rerenders the elements on your page when absolutely necessary. The way you tell React "hey, my state changed, can you update the page to reflect that" is by using state variables. In your example, React only rerenders the elements that reference the b variable when you update it using setB. However, it does not rerender the elements that represent a when you update it using a++, because it has no way to detect that a was updated.
useState is actually more efficient than local variables, because it rerenders only what is necessary.
see virchau13's answer.
Although saving to a state is more intensive than a simple variable assignment, you have to take into account that what you see on the screen will only change via renders. So if you wanted to see the display increment on the screen, it will only do so via renders, which is most easily achieved through state changes.
As i understand it, they both deal with state. Hooks seem to be more internal to a components state, while the context api seems to solve the problem of prop drilling, creating a more global state? Is this false? What am I missing?
Thanks a lot!
As I understand, they have completely different use cases. Context allows you pass a value deep into the component tree, where the value could be any kind of prop, say, a color. By using context in this way, you avoid having to do props.theme on every component that needs a theme color passed to it.
Hooks, on the other hand, replace the need for classes; instead you create a function and useState enables you to pass in variables. I.e. Hooks allow you to take a React function component and add state to it, and apply lifecycle methods like componentDidMount and componentDidUpdate. This is useful because if you find your function requires state, you don't need to refactor it into a class, you can just add Hooks. :) Of course this choice is contentious among developers though.
I'm currently implementing global state handling in React using the Context API in combination with the useReducer hook.
I have two concerns regarding mutability:
When updating state in my reducers, do I need to e.g use Lodash's cloneDeep function to sever the reference between the objects going into my reducer and the stored state?
Is it possible to ruin the global state by manually mutating it outside reducers, or will it behave like "normal React state" in the sense that manual mutations will get overwritten during the next update cycle?
For reference: docs
Both useState and useReducer give you the exact value reference that you saved (either by calling someSetter(newValue), or returning a value from the reducer function).
In either case, manually mutating the value is wrong. In particular, both of them will bail out of updates if you return the identical reference as last time, so you should always update values immutably.
I would give this a read.
https://kentcdodds.com/blog/how-to-use-react-context-effectively
This is a really good guide of how to use react context in conjunction with useReducer the right way.
Let me know if it helps.
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?
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.
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.
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.
I have an issue with redux state being updated successfully, but react component not re-rendering, after some research I believe [forceUpdate()][1] can solve my issue, but I am unsure of correct way to implement it i.e. after redux state updates. I tried looking up examples on github, but had no luck.
As others have said, forceUpdate() is basically a hack. You get updates for free whenever the props and state change. React and Redux work seamlessly together, so avoid any such hacks.
If your Redux state is updating correctly and your React view isn't, then it's most likely that you're not updating in an immutable fashion. Check your reducers.
It is possible that your issues is that the state you are updating is not a top level property. react calls a "shallowEqual" method to tell whether the props have updated. This means all top level properties, but if you are changing a deeper property and all the top level ones are the same then you will not rerender.
I'm not sure if this would be the case with redux maybe it's doing something more sophisticated but I know that is the workflow in react. It's worth taking a look.
That's not the solution you want.
Without looking at your code, it's impossible to tell what's actually wrong, but forceUpdate is not the solution. React will re-render if new data is placed in the state or props. If you're not re-rendering, it means you're data isn't getting all the way through.
Redux already doing forceUpdate with connect decorator. Maybe you miss this point in your component. This behaviour is explained on the Usage with React section of official documentation.