reactjs - 什么时候派生数据对于 redux 选择器来说过于复杂？

Question

常见的建议是保持状态最小并使用内存选择器(如重新选择库)来获取派生数据。我知道也有一些情况适合放在商店里。我的应用程序中有很多派生数据，生成这些数据的成本有点高，但由于其使用方式的性质，没有必要经常生成它。在什么时候数据太复杂而不适合选择器并且应该放入存储中？

<小时/>

更多详细信息:

我有时间序列数据，我对其运行一些计算以生成数据的派生“ View ”。每个 View 中的记录都是根据之前的所有记录计算的。

提供一个更具体、有些人为的示例:

目前我在没有 redux 的情况下在 indexedDB 中完成这一切。

我有一个主表，它纯粹是用户输入:

type Earnings = {
    id: number;
    time: Date;
    amount: number;
    category: 'A' | 'B' | 'C' | 'D';
};

我有一堆钩子(Hook)，可以在收入数据发生变化时生成“ View ”表。

type EarningsByDay = {
    id: number;
    date: Date; // only used to date part
    amountTotal: number;
    maxToDate: number;
};

type EarningsByDateAndCategory = {
    id: number;
    date: Date; // only used to date part
    category: 'A' | 'B' | 'C' | 'D';
    amountTotal: number;
    maxToDate: number;
};

在上面的 View 中，EarningsByDay 的 maxToDate 是通过从所有 EarningsByDay 中查找最大 amountTotal 来计算的日期 小于当前项目日期的记录。对于 EarningsByDateAndCategory 也是如此。

如果用户编辑/删除/插入过去的收入，则之后的所有派生数据都需要重新生成。然而，这种情况很少见，大多数时候用户会按时间顺序添加收入记录(这意味着我所要做的就是搜索过去的记录以找到最大值)。

作为迁移到 redux 计划的一部分，我计划仅将 Earnings 记录存储在 indexedDB 中，并在启动时将它们全部加载到存储中(一年的数据大约有 5,000 条记录)。然后我将使用派生“ View ”的选择器。

我担心这对于选择器来说太重了。另外，按照重新选择内存的方式，我最终会在附加记录时重新生成所有派生数据。

Answer 1

我一直按照问题中的描述使用重新选择，到目前为止还没有遇到任何问题。最大的缺点是状态的形状主要由一个主选择器而不是存储中的内容定义，这使得调试工具不太有用。然而，我发现这是调试工具的限制，而不是如上所述使用选择器的限制。调试时最好有一个选择器的 TreeView 。我同意这种权衡，因为代码最终变得更简单、更容易理解并且更容易测试。

更新:看起来正在进行一些工作来使调试选择器更容易:https://github.com/reactjs/reselect/issues/279