Is it considered bad practice to store classes in the state? I've read that the state should be easily serializable objects and classes break this convention.
I'm creating a web application that uses React/Redux with a set of backing models to collect information from the user.
So for example I have the following model:
class Person {
constructor(params = {}) {
this.firstName = params.firstName || '';
this.lastName = params.lastName || '';
this.gender = params.gender || '';
this.dateOfBirth = params.dateOfBirth || '';
this.stateOfResidence = params.stateOfResidence || '';
this.email = params.email || '';
}
validateField(args) {
// remove for brevity
}
valid(args) {
// remove for brevity
}
}
The object is added to the store by issuing the following actionCreator:
export function addPerson(args = {}) {
return (dispatch) => {
dispatch({
type: 'ADD_PERSON',
obj: new Person(args)
});
};
}
The appropriate person reducer sticks it into the state so I can get at it from the rest of the application.
This way when I grab the object from the state I can run it's validate and valid prototype functions to see if the model is valid and react appropriately.
Does this break React/Redux convention? What would be another way to approach this problem? What are the potential problems I might run into down the road with the above approach? Right now can't foresee any problems... but I also don't have much experience with React/Redux (~4 months)
Edit:
I should add that I only mutate the object state through the reducers. I am careful to not mutate state elsewhere in the application.
Redux can have only a single store in your application. Whenever a store is created in Redux, you need to specify the reducer. A reducer is a function that returns the next state of app. A preloadedState is an optional argument and is the initial state of your app.
There is no “right” answer for this. Some users prefer to keep every single piece of data in Redux, to maintain a fully serializable and controlled version of their application at all times. Others prefer to keep non-critical or UI state, such as “is this dropdown currently open”, inside a component's internal state.
For the most part if you have a react-redux app I would avoid local state entirely unless you can trying to solve a very component specific problem. For example I would use local state if my component does something on a setInterval and so it is keeping its own timer.
Designing the State Structure With Redux, our application state is always kept in plain JavaScript objects and arrays. That means you may not put other things into the Redux state - no class instances, built-in JS types like Map / Set Promise / Date , functions, or anything else that is not plain JS data.
Yes, it's generally considered an anti-pattern, because it breaks the ability to do things like time-travel debugging (one of Redux's core selling points). See the Redux FAQ at for further details.
If you do want to have more of an object-like facade over your plain data, you may want to look into something like redux-orm.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With