Question

我有一个情况类似的组件：

从服务器获取数据，并使用 status 更新页面的 reducer pending，success或fail通过调度。
mapStateToProps确实包含页面 reducer 中的页面 status ，自 {{ 1}} 键出现在status中。
我希望一旦this.props状态被调度后，shouldComponentUpdate就会触发，但是不会被调用，并且我的应用只会停留在“之间的状态，并且无法触发渲染，因为它依赖fail触发并告诉渲染 shouldComponentUpdate 是否为status以外的其他内容。

我注意到pending有时会在几次调度后被解雇，例如它在等待它们累积或不确定，等等。

有人知道为什么shouldComponentUpdate状态被分派后，shouldComponentUpdate不会在我最后一次分派后自动触发吗？

Answer 1

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

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

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

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

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

我有些新意，我不明白为什么render会在状态更改时被触发，但是渲染器的render并不关心这些特定的更改。

Redux分发后，shouldComponentUpdate不触发

我有一个情况类似的组件：

1 个答案: