相关疑难解决方法(0)

作为一个注释:我已经阅读了Redux的文档(Baobab也是如此),并且我已经做了很多Google搜索和测试.

为什么Redux应用程序只有一个商店？

我理解单店设置与多店设置的优缺点(在这个主题上有很多关于SO的问答).

IMO,这个架构决策属于应用程序开发人员根据他们的项目需求.那么为什么Redux如此强烈建议,几乎到了强制性的声音(虽然没有什么能阻止我们制作多个商店)？

编辑:转换为单店后的反馈

在使用redux处理许多人认为复杂的SPA之后几个月,我可以说单一商店结构一直是一种纯粹的乐趣.

有几点可能有助于其他人理解为什么单个商店与许多商店在很多很多用例中都是一个没有实际意义的问题:

• 它是可靠的:我们使用选择器来挖掘应用程序状态并获取与上下文相关的信息.我们知道所有需要的数据都在一个商店中.它避免了对状态问题可能存在的所有质疑.
• 速度很快:我们的商店目前有近100个减速机,如果不是更多的话.即使在那个数量上,只有少数减速器处理任何给定调度的数据,其他减少器只返回先前的状态.一个巨大/复杂的商店(减速器的数量)缓慢的论点几乎没有实际意义.至少我们没有看到任何性能问题.
• 调试友好:虽然这是使用redux作为一个整体的最有说服力的论据,但它也适用于单店和多店.在构建应用程序时,您必然会在进程中出现状态错误(程序员错误),这是正常的.PITA是那些错误需要几个小时才能调试的时候.多亏了单店(和redux-logger),我们在任何特定的州问题上都没有花费超过几分钟的时间.

一些指示

构建redux商店的真正挑战在于决定如何构建它.首先,因为在路上改变结构只是一个主要的痛苦.其次,因为它在很大程度上决定了您将如何使用,并查询您的应用数据的任何过程.关于如何构建商店有很多建议.在我们的例子中,我们发现以下是理想的:

{
  apis: {     // data from various services
    api1: {},
    api2: {},
    ...
  }, 
  components: {} // UI state data for each widget, component, you name it 
  session: {} // session-specific information
}

希望这些反馈能够帮助他人.

编辑2 - 有用的商店工具

对于那些一直想知道如何"轻松"管理单个商店的人来说,这可能会很快变得复杂.有一些工具可以帮助隔离商店的结构依赖性/逻辑.

有Normalizr其标准化基础上的模式数据.然后它提供了一个界面来处理数据并获取数据的其他部分id,就像字典一样.

当时不知道Normalizr,我沿着同样的路线建造了一些东西.relational-json接受一个模式,并返回一个基于表的接口(有点像数据库).relational-json的优点是您的数据结构动态地引用数据的其他部分(实际上,您可以在任何方向上遍历数据,就像普通的JS对象一样).它不像Normalizr那样成熟,但我已经在生产中成功使用它几个月了.