我一直在处理Redux 中的TodoMVC example，我注意到一些有趣的事情：应用程序将待办事项的CRUD 交给store，但通过在组件之间传递constants 来专门处理过滤器状态，即the footer 和the list view。
这里的经验法则是什么？我很欣赏过滤器状态可能永远不会保存到持久存储中（可能作为用户配置文件的一部分除外），但也感觉将过滤器状态保留在存储之外有点与通量哲学不一致。为什么不将更新过滤器状态委托给商店？
【问题讨论】：
标签： reactjs reactjs-flux flux
我会说这归结为用例 + 个人偏好。在这个简单的应用程序中，filter 在两个具有父子关系的组件之间共享，但在其他任何地方都没有。在这种情况下这当然没问题。
您会看到这样的设置的好处是简化/更小的商店。我目前正在使用Reflux 构建一个应用程序，并且我的一个商店已经膨胀到我正在考虑如何分解它或者是否可以删除任何数据的地方。
对于较小的商店（至少在 Reflux 中）的另一个好处是更少的事件分派，这可能意味着更少的 DOM 渲染（或至少更少的虚拟 DOM 重新计算）。
（保留Reflux 的警告），为商店设置侦听器的“简单”方法有助于重新渲染组件以更改任何属性，即使该组件只关心 1 或2. 回到我的大型商店问题，此时它包含大约 10 个属性。许多组件都连接到它，这 10 个属性中的 1 个是相当不稳定的。这会导致所有侦听器组件比必要的更频繁地通过虚拟 DOM。因此，我还定义了很多 shouldComponentUpdate 函数，否则我不需要它们。
当然，将filter 作为道具传递给Footer 的一个缺点是它如何影响DOM 布局。 IE。 Footer 必须是 MainSection 的子级。这足以让我想将filter 放入商店，尽管开销很大。
IMO，最明显的缺点是 filter 数据在应用程序的其他地方根本不可用。根据您的情况，这可能是正数或负数，但我倾向于认为它通常是负数。
【讨论】：