我解决了我的问题,但我猜没有正确的答案,因为它真的取决于具体的情况.就我而言,我决定采用这种方法：

原始选择器处理得很好的挑战之一是最终信息是从以任意顺序传递的许多部分编译而来的.如果我决定逐步在Reducer中构建最终信息,我必须确保计算所有可能的场景(信息块可能到达的所有可能的顺序)并定义所有可能状态之间的转换.然而,通过重新选择,我可以简单地拿走我现在拥有的东西并从中取出一些东西.

为了保持这个功能,我决定将选择器逻辑移动到包装父减速器中.

好吧,让我们说我有三个减速器,A,B和C,以及相应的选择器.每个处理一条信息.该部分可以从服务器加载,也可以来自客户端的用户.这将是我原来的选择器：

const makeFinalState(a,b,c) => (new List(a)).map(item =>

new MyRecord({ ...item,...(b[item.id] || {}),...(c[item.id] || {}) });

export const finalSelector = createSelector(

[selectorA,selectorB,selectorC],(a,c) => makeFinalState(a,c,));

(这不是实际的代码,但我希望它有意义.请注意,无论各个reducer的内容可用的顺序如何,选择器最终都会生成正确的输出.)

我希望我的问题现在很明确.如果任何这些reducer的内容发生变化,则从头开始重新计算选择器,生成所有记录的全新实例,最终导致React组件的完全重新呈现.

我目前的解决方案看起来很简单

export default function finalReducer(state = new Map(),action) {

state = state

.update('a',a => aReducer(a,action))

.update('b',b => bReducer(b,action))

.update('c',c => cReducer(c,action));

switch (action.type) {

case HEAVY_ACTION_AFFECTING_A:

case HEAVY_ACTION_AFFECTING_B:

case HEAVY_ACTION_AFFECTING_C:

return state.update('final',final => (final || new List()).mergeDeep(

makeFinalState(state.get('a'),state.get('b'),state.get('c')));

case LIGHT_ACTION_AFFECTING_C:

const update = makeSmallIncrementalUpdate(state,action.payload);

return state.update('final',final => (final || new List()).mergeDeep(update))

}

}

export const finalSelector = state => state.final;

核心思想是：

>如果发生了重大事件(即我从服务器获得了大量数据),我将重建整个派生状态.

>如果发生了一些小的事情(即用户选择了一个项目),我只是在原始的reducer和包装父减速器中进行快速增量更改(存在一定的重复性,但是必须实现一致性和良好的性能) .

与选择器版本的主要区别在于我总是将新状态与旧状态合并. Immutable.js库非常智能,如果它们的内容完全相同,则不会用新的Record实例替换旧的Record实例.因此保留了原始实例,因此不会重新呈现相应的纯组件.

显然,深度合并是一项代价高昂的操作,因此这对于非常大的数据集不起作用.但事实是,与React重新渲染和DOM操作相比,这种操作仍然很快.因此,这种方法可以在性能和代码可读性/简洁性之间做出很好的折衷.

最后的注意事项：如果不是单独处理那些轻量级动作,那么这种方法基本上等同于用纯组件的shouldComponentUpdate方法中的deepEqual替换shallowEqual.