1

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?

George Welder
  • 3,787
  • 11
  • 39
  • 75

2 Answers2

4

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.

Community
  • 1
  • 1
markerikson
  • 63,178
  • 10
  • 141
  • 157
1

One practical tip I can give you is to avoid putting "current pupil" data in the redux store. Instead, just have a collection of pupils in the store, indexed by id and have your react components select data from redux store based on the current url ( eg. on page /pupils/345, have your components use the data for user 345 ).

This doesn't mean that you need to have data for all pupils in redux. The redux state is kind of a database, but it only represents the information that your client knows about. E.g. when user arrives on page /pupils/345, if there is no pupil 345 in redux, then trigger an action that fetches that data from the server.

For current UI state, the main point is to keep the data in one location, "single source of truth". That one location can be:

  • Current url (with react-router): perfect for "which view is active"
  • Redux store: good when it's something that affect multiple separate components, e.g. current language
  • The state of a single, stateful component (good solution if the state is local to one component and you don't need the extra power and complexity of redux)
OlliM
  • 7,023
  • 1
  • 36
  • 47