ReactJS - реквизит против штата + дизайн магазина

Question

Представьте себе следующее: вы пишете приложение «умный дом», которое управляет температурой в вашем доме.

На мой взгляд, я хотел бы:

• см текущую температуру для каждой комнаты
• набор требуемую температуру для каждой комнаты
• увидеть, включен ли кондиционер вкл/выкл для каждой комнаты

Существует внешнее устройство, связывающее ваше приложение с помощью websockets (оно периодически отправляет текущую температуру, состояние кондиционера).

Я вижу два варианта там:

1) Создать один 'большой' магазин containging структуры данных, такие как:

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

Там будет TemperatureManager компонент (или нечто подобное). Он будет иметь состояние и получать его из магазина периодически. Тогда он просто распределит часть государства своим потомкам (т.е. RoomTemperatureManager, RoomSystemSensorManager), передавая его как реквизит.

Если что-либо изменится (например, температура в спальне), оно при необходимости доставит все данные из магазина и повторно отобразит его потомков.

2) Второе решение

сделать RoomTemperatureManagers и RoomSystemSensorManagers имеют свое собственное государство. Это также связано с наличием автономных хранилищ как для температуры, так и для SystemSensorState.

Эти магазины тогда имели параметризованные геттеры (т.е. getSensorState (roomName)) вместо методов для извлечения всех данных.

Вопрос:

Какой вариант лучше?

Дополнительный вопрос:

Это хорошо для компонентов листа (т.е. один отвечает за управление требуемой температуры) для вызова ActionCreator напрямую? Или, может быть, только Supervising Component должен знать что-либо о ActionCreator и должен передать надлежащий метод как свойство его потомкам?

Answer 1

В 2 варианта, которые вы описываете в вашем посте действительно 2 diffent вопросы:

1. Один большой магазин или несколько различных магазинов?
2. Должны ли дочерние компоненты (RoomTemperatureManager) иметь собственное состояние или получать реквизит из магазина?

Объявление 1. Один большой магазин проще, если он не усложняется. Правило большого пальца, которое я использую: если в вашем магазине есть> 300 строк кода, возможно, лучше разделиться в разных магазинах.

Объявление 2. Реквизит обычно лучше, чем состояние. Но в вашем случае, я думаю, вам понадобится состояние, например. ваш температурный менеджер: вы устанавливаете температуру в своем приложении (и хотите видеть, что отражается на каком-то слайдере или что-то еще). Для этого вам нужно состояние.

• Состояние немедленно обновляет интерфейс (оптимистическое обновление).
• Затем компонент отправляет действие set_temparature на датчик в доме .
• Затем датчик в доме подтверждает, что он установил новую температуру в ваше приложение.
• Обновление (-и) магазина (ов) и изменение эмиссии.
• Настройка температуры от датчика в доме передается в виде реквизитов для вашего диспетчера температуры.
• Менеджер температуры делает все, что ему нужно (просто обновите состояние с помощью нового прокрутки, сообщения подтверждения дисплея или хорошего сообщения об ошибке, если все пойдет по цепочке связи).

Answer 2

Я считаю, что наилучшим подходом было бы делегирование. Ваш Температурный регулятор должен иметь механизм уведомления слушателей о том, что есть обновление, и в свою очередь диспетчер Room (Temperature | System) отправит в качестве слушателя обратный вызов, который будет потреблять обновленные данные и соответствующим образом изменять состояние.Это позволит использовать виртуальную разницу DOM, так что будут отображаться только изменения, а не все части, повторно отображаемые, а также создать единую точку, которая будет связываться с Магазином. Менеджер комнаты (температура | система) должен поддерживать связь только с Магазином, если есть обновление, которое необходимо выполнить с моделью, с которой она работает.

Температурный регулятор может быть улучшен, если при подписке вы можете указать, какие данные необходимо прослушивать для получения обновлений. Он не должен предполагать, что конкретный «менеджер» должен получить любой поднабор данных.