常见的建议是保持状态最小，并对派生数据使用记忆选择器(如重新选择库(。我知道在某些情况下，将其放在商店中是合适的。我的应用程序中有很多派生数据，生成这些数据的成本有些高，但由于其使用方式的性质，没有必要经常生成它。在什么时候数据太复杂而不适合选择器，应该放入存储中？
更多详情：
我有时间序列数据，我在其上运行一些计算以生成数据的派生"视图"。每个视图中的记录都是根据之前的所有记录计算的。
为了提供一个更具体、有点做作的例子：
目前，我在索引数据库中执行所有这些操作，而无需 redux。
我有一个纯粹是用户输入的主表：
type Earnings = {
id: number;
time: Date;
amount: number;
category: 'A' | 'B' | 'C' | 'D';
};
我有一堆钩子，当Earnings数据发生变化时，它们会生成"视图"表。
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;
};
在上面的视图中，EarningsByDay的maxToDate是通过从date小于当前项目的日期的所有EarningsByDay记录中查找最大amountTotal来计算的。同样对于EarningsByDateAndCategory.
如果用户编辑/删除/插入过去的收入，则需要重新生成之后的所有派生数据。但是，这种情况很少见，大多数情况下用户将按时间顺序添加Earnings记录(这意味着我所要做的就是搜索过去的记录以找到最大值(。
作为我迁移到 redux 计划的一部分，我计划只将Earnings条记录存储在 indexedDB 中，并在启动时将它们全部加载到存储中(一年的数据大约有 5,000 条记录(。然后，我将为派生的"视图"使用选择器。
我担心的是这太重了，不适合选择器。此外，重新选择记忆的方式，我最终会在附加记录时重新生成所有派生数据。
我一直在按照问题中的说明使用重新选择，到目前为止还没有遇到任何问题。最大的缺点是状态的形状主要由一个主选择器定义，而不是存储中的内容，这使得调试工具不太有用。但是，我发现这是调试工具的限制，而不是使用选择器的限制。调试时最好有一个选择器的树视图。我可以接受权衡，因为代码最终变得更简单、更容易理解和更容易测试。
更新：看起来有一些工作正在进行中，以使调试选择器更容易：https://github.com/reactjs/reselect/issues/279