But the question remains, what application state (like interface state) do you leave out of Redux?
As a rule of thumb, any shared state in your application would live in your redux store. Any state specific to a single component, should live within that component.
The main thing you want to avoid is using redux as the state for your controlled/uncontrolled components. You usually want to use class state to handle the events (onChange, onClick) and in some cases, transfer that state to a redux store using debouncing. If you were to debounce the onChange event, the UI would seem slow and janky.
Note for most use cases, just using the class/component state should be sufficient. Redux is for more advanced use cases and shared state.
I work on a production application which a piece of, in a simple sense can be thought of as a form. Our form has different fields, but depending on the user, not always the same fields. Regardless of what fields are displayed, we need to validate and submit the data.
We keep event based state directly in the component, then debounce changes to our redux store where we store the entire state of the form as well as having dispatcher's which validate and submit the stored form data.
Maybe not the most convential use case, but may convey the layer of separation a bit.
I might have rambled a bit there, hopefully helpful!
Thanks for the reply. I didn't think anyone would respond. Since this seems like a really cool community, I should probably put questions in a more apparent place in my posts.
I thought I had read a lot about Redux, but your post is the first place I've seen that mentions what kind of data can exist outside of Redux. Or, at least the first place I've noticed it.
I thought of Redux as a framework which, if employed, all state is managed by it. However, your experience is of keeping controlled/uncontrolled component state out of it and instead using Redux as just a place to share state across the application. And complex state, at that.
The more I think of your example, the more I see the benefit of keeping that complex state in one concise and controlled place to then submit at a later date.
This was my first Redux project past the tutorial documentation. For my next project that uses Redux/React I will definitely keep your input in mind. Thanks for the comment, it helped me out a lot!
No problem 😊 glad it was of some use to you.I don't post on here often, trying to make it a more regular thing. Definitely an amazing community here.
There's a bunch of good articles on the interwebs which provide other real world examples as well. This is a good one blog.logrocket.com/why-use-redux-r... as well as anything along the lines of "you might (not) need Redux", a few by Dan Abramov himself!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As a rule of thumb, any shared state in your application would live in your redux store. Any state specific to a single component, should live within that component.
The main thing you want to avoid is using redux as the state for your controlled/uncontrolled components. You usually want to use class state to handle the events (onChange, onClick) and in some cases, transfer that state to a redux store using debouncing. If you were to debounce the onChange event, the UI would seem slow and janky.
Note for most use cases, just using the class/component state should be sufficient. Redux is for more advanced use cases and shared state.
I work on a production application which a piece of, in a simple sense can be thought of as a form. Our form has different fields, but depending on the user, not always the same fields. Regardless of what fields are displayed, we need to validate and submit the data.
We keep event based state directly in the component, then debounce changes to our redux store where we store the entire state of the form as well as having dispatcher's which validate and submit the stored form data.
Maybe not the most convential use case, but may convey the layer of separation a bit.
I might have rambled a bit there, hopefully helpful!
Thanks for the reply. I didn't think anyone would respond. Since this seems like a really cool community, I should probably put questions in a more apparent place in my posts.
I thought I had read a lot about Redux, but your post is the first place I've seen that mentions what kind of data can exist outside of Redux. Or, at least the first place I've noticed it.
I thought of Redux as a framework which, if employed, all state is managed by it. However, your experience is of keeping controlled/uncontrolled component state out of it and instead using Redux as just a place to share state across the application. And complex state, at that.
The more I think of your example, the more I see the benefit of keeping that complex state in one concise and controlled place to then submit at a later date.
This was my first Redux project past the tutorial documentation. For my next project that uses Redux/React I will definitely keep your input in mind. Thanks for the comment, it helped me out a lot!
No problem 😊 glad it was of some use to you.I don't post on here often, trying to make it a more regular thing. Definitely an amazing community here.
There's a bunch of good articles on the interwebs which provide other real world examples as well. This is a good one blog.logrocket.com/why-use-redux-r... as well as anything along the lines of "you might (not) need Redux", a few by Dan Abramov himself!