So I believe there are different ways of using Redux, and I am not sure whether this is a good idea at all, or whether what I am doing right now is completely wrong. Say I have a software which manages schools (classes & pupils etc.). The way I am using Redux right now, is as follows:
1
I would first, store the application state: Which pupil is selected, which view is currently active, what checkboxes are checked. I would also have a separate reducer for preferences - that is, what the user selects in his or her preference settings. So for example, the language of the software.
This seems different to me from the idea of storing application state, since many of the things that have to do with the application state are not preferences, but simply what is currently selected. Does this division make sense, or would you advice against this?
2 Then, furthermore, I am also using Redux to hold data, so I am kind of using it as a database. In my case, I would load a json completely into my store, and then continue working with this. I would thus not only have the active pupil in my Redux store (which would be the application state proper), but (in a different reducer) every pupil, and then depending on what's needed, feed the other reducers with the active ones etc.
Is this bad practice? Should I try to outsource this completely into a 'proper' database?
There's a good article called The 5 Types of React Application State that tries to categorize different kinds of data in your application. It's up to you which of those you decide to put into Redux. Quoting the Redux FAQ on what to put into Redux:
Some common rules of thumb for determing what kind of data should be put into Redux:
- Do other parts of the application care about this data?
- Do you need to be able to create further derived data based on this original data?
- Is the same data being used to drive multiple components?
- Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)?
- Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
So, it's totally fine to store both fetched data and local application state in Redux.
When you follow the suggested practice of normalizing state in your Redux store, Redux itself becomes kind of like a client-side database. My "Practical Redux" tutorial series shows examples of tracking what item in a list is currently selected, and implementing editing of a currently selected item.