Redux-多家商店,为什么不呢?
注意:我已经阅读了Redux(Baobab,也是如此)的文档,并且做了很多Google搜索和测试工作。 为什么强烈建议Redux应用程序只有一个商店? 我了解单商店设置与多商店设置的优缺点(关于此主题,有很多关于SO的问答)。 IMO,这个架构决定是基于应用程序开发人员的项目需求。那么,为什么如此强烈地建议Redux使用,几乎达到强制性的程度(尽管没有什么阻止我们开设多个商店)? 编辑:转换为单店后的反馈 在与redux一起工作了几个月后,许多人认为它是复杂的SPA,我可以说单一的商店结构让我感到很高兴。 以下几点可能会帮助其他人理解为什么在许多很多用例中,单商店还是多商店是一个有争议的问题: 可靠:我们使用选择器来挖掘应用程序状态并获取与上下文相关的信息。我们知道所有需要的数据都在一个存储中。它避免了所有关于国家问题可能在哪里的质疑。 速度很快:我们的商店目前有将近100个减速器,如果没有更多的话。即使达到这个数量,也只有极少数的减速器在任何给定的调度上处理数据,其他的只是还原以前的状态。关于大型/复杂存储(reducers的nbr)缓慢的说法几乎没有意义。至少我们还没有看到任何性能问题。 调试友好:虽然这是整体上使用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,就像一个Dictionary。 当时我还不了解Normalizr,所以我沿相同的思路建立了一些东西。Relational-json采用一个模式,并返回一个基于Table的接口(有点像一个数据库)。Relational-json的优点是您的数据结构可以动态引用数据的其他部分(本质上,您可以像正常的JS对象一样在任何方向上遍历数据)。它不如Normalizr成熟,但是我已经在生产中成功使用了几个月。