Designing the redux store: What are standard design practices

Viewed 1095

I am new to redux and have come up with an architecture that seems wrong. I am hoping someone can explain to me a better way to architect my application.

The short of it is that I wanted to follow the idea of keeping the redux store as flat as possible but with that I have ended up with a store that is one giant object of objects. I have only 1 reducer and 1 action. This all seems just wrong to me. But then, my application is pretty limited.

Background information I'm designing an app that will communicate via blue tooth with a medical device. For a given screen, before rendering I will need to fetch the data items of interest. The set of data items on the device is fixed and known beforehand. The app is merely a tool for displaying them and possibly updating them.

Example The 'Information Screen' displays information about the current state of the device. For simplicity lets say the screen will just display some items in a column. The items are

  • Volume
  • Rate
  • Interval
  • isIntervalEnabled

I will need to send a fetch command to the device for each data item one at a time. The device should then (at some point) send a response containing the data for each of the items in question. The response should update the store so that these items are available by the time mapStateToProps is passed to connect.

Current Architecture of the store and how I am retrieving items from store At this point I feel as though my redux store is just a big data base. Since I know all of the data items I will need from the device in advance, I decided to just initialize the state with all of these data items.

{
  volume: {amount: 30, units: ML},
  rate: {amount: 30, units: ML},
  interval: {amount: 20: units ML_PER_HOUR},
  isIntervalEnabled: true
}

Note that in this example these are just dummy values, in actuality, the keys would have values of undefined and only a response from the device and update to the store could give value to an item

I created selectors for each of the items in a separate file that look something like this.

const volume = (state) => state.volume;
const volumeSelector = createSelector([volume], (volumeObject) => volumeObject);

Each item has this type of structure. Note here that createSelector is from the reselect library.

At the bottom of 'Device Information' screen I have mapStateToProps function like this

function mapStateToProps(state){
  return {
           volume: volumeSelector(state),
           rate: rateSelector(state)
           interval: intervalSelector(state)
           isIntervalEnabled: intervalSelector(state)
         }
}

(In reality I have like 30 items I am getting from the device) And some screens will also not only want to get info from the device but send information to the device. For that purpose, I wrote an actions like this

actionUpdate(deviceItemId, propsToUpdate){
  return {type: "Update", deviceItemId, propsToUpdate}
}

And a reducer like this

updateRecuder(state, action){
    const theProps = action.propsToUpdate
    const theId = action.deviceItemId,
    const updatedItem = <merge state[theId] with theProps>
    return state merged with updatedItem
}

What this then means is I have about 30 device items 1 reducer 1 action which seems totally different then anything else I have seen in others redux projects. In a sense it seems I'm just using redux like a data base. Im wondering

  1. Is what I am doing a bad idea and why?
  2. How can I re-architect this thing so I am following standard redux patterns
1 Answers

Redux is pretty flexible and lets you do many things like having 2 stores. From my understanding, you did everything correctly. Don't be afraid to make more reducers and actions if it makes the code more readable.

https://redux.js.org/basics/dataflow

As long you follow the data flow, you should be fine : )

Related