javascript - 如何在大型规范化 Redux 存储中组织 reducer

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: {} }
};

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

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

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

这部分只是为了澄清

这就是它们的意思(它是一个跟踪你吃什么的应用程序):

• diaryEntry代表日记中的食物； 食物位于食物组中，具有数据源。食物还具有营养表和>测量单位;
• MeasurementSystems、measurementUnits 和 sameTypeUnitConverter 用于存储厘米、米和磅等度量单位的精确信息。
• BodyMeasurementTypes、bodyMeasurements 和 uniqueBodyMeasurements 用于跟踪用户测量数据，例如胸部尺寸。
• MealSettings 和 bodyMeasurementShortcutSettings 是应用 UI 的设置。

Answer 1

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

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

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

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

4. 目标也可以是商店的单独部分，因为它们可以显示在应用的其他部分(而不是 diaryEntries 或 显示 body 测量值)。并且可以允许用户设定他/她的目标。所以最好把目标放在第四部分。

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

例如

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

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