Search code examples
reactjsreactjs-fluxflux

ReactJS - props vs state + Store designing


Imagine the following: you're writing a 'smart-house' application which manages a temperature in your house.

In my view I'd like to:

  • see current temperature for each room
  • set desired temperature for each room
  • see whether air conditioning is turned on/off for each room

There is an external device, communicating with your aplication via websockets (it is periodically sending current temperature, air conditioning status).

I see two options there:

1) Create one 'big' store containging data structures like:

var _data = [
   name: 'Kitchen',
   currentTemperature: 25,
   desiredTemperature: 22,
   sensors: [
       {
           name: 'Air Conditioning'
           state: 'on'
       }
       ... there might be other sensors too ...
   ]
]

There will be a TemperatureManager component (or something similar). It would have a state and fetch it from Store periodically. Then it would just distribute part of the state to his descendants (ie RoomTemperatureManager, RoomSystemSensorManager), passing it as props.

If anything changes (for example, temperature in the bedroom), it will fetch all data from store and re-render its descendants if necessary.

2) The second solution is

to make RoomTemperatureManagers and RoomSystemSensorManagers have their own state. It is also related to having standalone stores for both Temperature and SystemSensorState.

Those Stores would then have parametrized getters (ie getSensorState(roomName)) instead of methods to fetch all data.

Question:

Which option is better?

Additional question:

Is it okay for leaf components (ie the one responsible for managing desired temperature) to call ActionCreator directly? Or maybe only the Supervising Component should know anything about ActionCreator and should pass proper method as a property to his descendants?


Solution

  • The 2 options you describe in your post are really 2 diffent questions:

    1. One big store or several different stores?
    2. Should child components (RoomTemperatureManagers) have their own state or receive props from store?

    Ad 1. One big store is easier, as long as it does not get to complicated. Rule of thumb that I use: if your store has > 300 lines of code, probably better to separate in different stores.

    Ad 2. Props are generally better than state. But in your case, I would think you will need state in e.g. your Temperature-manager: you set the temperature in your app (and want to see that reflected in some slider or whatever). For this, you will need state.

    • State updates the front-end immediately (optimistic update).
    • The component then sends of a set_temparature action to a sensor in the house.
    • Then the sensor in the house confirms that it has set the new temperature to your app.
    • The store(s) update(s) and emit change.
    • The temperature setting from the sensor in the house is communicated as props to your Temperature manager.
    • The Temperature manager does whatever it needs to do (simply update state with new prop, display confirmation message, or nice error message if things broke down along the communication chain).