ReactJS - 道具与州+店铺设计

时间:2015-04-26 09:51:12

标签: reactjs reactjs-flux flux

想象一下: 你正在编写一个“智能家居”应用程序来管理你家中的温度。

在我看来,我想:

  • 查看每个房间的当前温度
  • 为每个房间设置所需的温度
  • 了解每个房间是否打开/关闭空调

有一个外部设备,通过websockets与您的应用程序通信(它定期发送当前温度,空调状态)。

我在那里看到两个选项:

1)创建一个包含以下数据结构的“大型”商店:

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

将有一个 TemperatureManager 组件(或类似的东西)。它会有一个状态并定期从Store中获取它。 然后它只是将状态的一部分分配给他的后代(即 RoomTemperatureManager,RoomSystemSensorManager ),将其作为道具传递。

如果有任何变化(例如,卧室内的温度),它将从商店获取所有数据,并在必要时重新渲染其后代。

2)第二个解决方案是

使 RoomTemperatureManagers RoomSystemSensorManagers 拥有自己的状态。它还与为Temperature和SystemSensorState提供独立存储。

那些商店将具有参数化的getter(即getSensorState(roomName)),而不是获取所有数据的方法。

问题:

哪个选项更好?

其他问题:

叶子组件(即负责管理所需温度的组件)可以直接调用ActionCreator吗?或者也许只有监督组件应该知道关于ActionCreator的任何信息,并且应该将正确的方法作为属性传递给他的后代?

2 个答案:

答案 0 :(得分:1)

您在帖子中描述的两个选项实际上是两个不同的问题:

  1. 一家大商店还是几家不同的商店?
  2. 子组件(RoomTemperatureManagers)是否有自己的状态或从商店接收道具?
  3. 广告1.一个大商店更容易,只要它不复杂。我使用的经验法则:如果您的商店有> 300行代码,可能最好在不同的商店中分开。

    广告2.道具通常比州更好。但在你的情况下,我认为你需要在你的温度管理器:你在你的应用程序中设置温度(并希望看到反映在某些滑块或其他任何东西)。为此,你需要国家。

    • State立即更新前端(乐观更新)。
    • 然后,组件将set_temparature动作发送到传感器中 屋。
    • 然后房子里的传感器确认它已经设置了新的 温度到你的应用程序。
    • 商店更新并发出更改。
    • 来自房屋中的传感器的温度设置被传达为 温度管理器的道具。
    • 温度管理器会做任何需要做的事情(如果事情在通信链上发生故障,只需用新道具更新状态,显示确认消息或错误消息)。

答案 1 :(得分:0)

我认为最好的方法是委派。您的 TemperatureManager 应该有一种机制来通知侦听器有更新,反过来,房间(温度|系统)管理器将作为侦听器发送一个将消耗的回调更新的数据并相应地更改状态。这将利用虚拟DOM差异,因此仅显示更改,而不是重新呈现整个部分,以及创建与Store通信的单个点。 会议室(温度|系统)管理员只有在需要对其正在使用的模型进行更新时才应与商店进行通信。

如果订阅时,可以改进

TemperatureManager ,您可以指定要监听哪些数据以进行更新。它不应该假设特定的“经理”应该获得任何数据子集。