如何在大型标准化 Redux 存储中组织减速器

Question

我已经阅读了 Redux 网站上的官方文档、一些在线文章以及 StackOverflow 上关于此主题的一些问题，但我仍然不知道如何组织我的状态。

然后我进行了规范化，因为某些实体具有对同一对象的引用，并且处理它会变得有问题。

所以，在规范化之后，这就是我的状态：

state: {
    measurementSystems: { 0: {}, 1: {} },
    measurementUnits: { 0: {}, 1: {} },
    sameTypeUnitConverters: { 0: {}, 1: {} },
    bodyMeasurementTypes: { 0: {}, 1: {} },
    bodyMeasurements: { 0: {}, 1: {} },
    bodyMeasurementShortcutSettings: { 0: {}, 1: {} },
    uniqueBodyMeasurements: { 0: {}, 1: {} },
    nutritionalTables: { 0: {}, 1: {} },
    dataSources: { 0: {}, 1: {} },
    foodGroups: { 0: {}, 1: {} },
    foods: { 0: {}, 1: {} },
    diaryEntries: { 0: {}, 1: {} },
    mealSettings: { 0: {}, 1: {} },
    goals: { 0: {}, 1: {} },
    users: { 0: {}, 1: {} }
};

我的问题是：如何为这种标准化状态编写减速器？我应该为每个状态编写一个减速器，然后处理相同的操作吗？或者我应该为每个操作创建一个减速器并让这个减速器管理所有状态？

例如，如果我每个状态有一个减速器并发送一个动作 REMOVE_DIARY_ENTRY。我将不得不让所有在 diaryEntry 中有引用的状态来处理此操作并检查它们是否需要删除已删除的引用。但是我将如何进行这些检查？

否则，如果我每个动作都有一个 reducer，这些 reducer 可以开始执行非常相似的任务，并与当前状态架构非常耦合。

这部分只是为了澄清

这是他们的意思（它是一个跟踪你吃的应用程序）：

• 一个diaryEntry代表日记中的一个食物； food 位于具有 dataSource 的 foodGroup 中。 食物还具有 nutritionalTable 和 >测量单位;
• MeasurementSystems、measurementUnits 和 sameTypeUnitConverter 用于存储厘米、米和磅等度量的精确信息。
• BodyMeasurementTypes、bodyMeasurements 和 uniqueBodyMeasurements 用于跟踪用户测量值，例如胸围。
• MealSettings 和 bodyMeasurementShortcutSettings 是应用 UI 的设置。

Answer 1

我建议首先考虑将哪些操作分派到商店以及如何使用商店信息。这使您可以决定如何更好地拆分存储。

1. 可以从想要显示和修改存储以响应用户迭代的组件中调度和存储操作。例如，您可能有一个表格或列表来显示 diaryEntries 给用户和另一个 - 显示 bodyMeasurements。并且用户可能想要设置 bodyMeasurements 或添加 diaryEntry。因此，您可以考虑将 diaryEntries、food 和相关实体分组到商店的一个部分，而将 bodyMeasurements 分组到另一部分。 （这可以根据 React 组件如何使用数据进行逻辑划分）

2. MeasurementSystems 和 measurementUnits 可能无法由用户修改（它们可能由管理员设置或在数据库中预加载）。因此可以将它们视为目录并放在名为Catalogs 的商店的单独部分中。它们可以使用REQUEST_CATALOGS 和RECEIVE_CATALOGS 操作从后端加载，并在应用中保持只读状态。

3. 用户列表可以是商店的第三方，例如可以由应用管理员修改。或者可以和其他部分分开

4. goals 也可以是商店的独立部分，因为它们可以显示在您应用的其他部分（不在 diaryEntries 或 的部分bodyMeasurements 显示）。并且可以允许用户设置他/她的目标。所以最好把目标放在第四部分。

另一种方法是考虑如何从后端获取实体并将其保存回来。如果一次获取所有实体更好，您可以将所有实体留在存储的一部分中。可能仅将只读实体与可写实体分开。并具有像CHANGE_ENTITY 这样的通用操作，它将在有效负载中携带entityType。 entityType 将是 diaryEntries 或 bodyMeasurements 或用户想要修改的任何其他内容。

例如

{ type: 'CHANGE_ENTITY', entityType: 'diaryEntries', key: 0, value: 'some value' }

通过这种方法，所有商店都可以是单片的。