shouldComponentUpdate 在 Redux 调度后未触发答案

【问题标题】：shouldComponentUpdate not firing after a Redux dispachshouldComponentUpdate 在 Redux 调度后未触发
【发布时间】：2018-10-05 15:59:37
【问题描述】：

我有一个组件有这样的情况：

从服务器获取数据并将页面的 reducer 更新为 status pending、success 或 fail 通过调度。
mapStateToProps 确实包含页面 reducer 中的页面 status，因为 status 键是出现在this.props。
我希望shouldComponentUpdate 在我收到fail 状态调度后触发，但它确实不会被调用，而且我的应用只是停留在“介于”状态，无法触发如果 status 是除pending 之外的任何内容，它依赖于shouldComponentUpdate 触发并告诉它渲染。

我注意到shouldComponentUpdate 有时会在几次分派后被解雇，就像它在等待它们累积或其他什么，不确定..

有人知道为什么shouldComponentUpdate 没有在我最后一次发送后自动触发fail 状态被发送吗？

【问题讨论】：

你能显示任何代码吗？
我不想发布代码，因为我确定这是我的特定代码中的内容，因为我创建的简化测试没有重现它。

标签： javascript reactjs redux react-redux

【解决方案1】：

我发现了问题所在；在shouldComponentUpdate里面我写道：

return this.props.status != 'pending';

因为我认为 Redux 更改状态后的生命周期会反映在 this.props 中，但我真正应该做的是使用 nextProps.status，因为 nextProps 暴露为 shouldComponentUpdate 参数：

shouldComponentUpdate( nextProps, nextState ){
   return nextProps.status.status != 'pending';
}

这一切背后的想法是不要触发大量的render 调用，因为我的商店有许多来自后台数据提取的调度，直到收到所有需要的数据，并且每个dispatch 都为此更新了props render 方法被调用了很多次，我确实（仍然）不相信 React 如果没有实际进行任何更改就不会实际重新渲染 DOM 应该反映在 DOM 更改中，但是，render 被解雇了。

我有点新反应，我不明白为什么render 会在状态改变时被解雇，但渲染的JSX 并不关心这些具体的变化..

【讨论】：