为了响应状态更改,我想触发另一个状态更改。这本质上是一个坏主意吗?
具体的场景是,组件被建模为状态机,根据this.state.current_state
的值呈现不同的信息。但外部事件可以通过通量存储改变其状态,促使其经历状态转换。这是一个为了传达这个想法而设计的场景:
我认为执行此操作的正确生命周期方法是 shouldComponentUpdate
。与此相关的一些内容:
shouldComponentUpdate: function(nextProps, nextState) {
if (nextState.counter > 4 && this.state.current_state !== DISPLAY_MANY) {
this.setState({ current_state: DISPLAY_MANY });
}
return true;
}
在某些子组件中,counter
可能会增加,因此我不想根据某些counter
变量的值推断它将显示的内容,而是想进行编码明确规定。
真实的场景比这更复杂,但希望这个场景足够详细,能够让大家理解这个想法。可以按照我的想法去做吗?
编辑:修复了代码示例,以避免通过添加额外的状态条件触发无限循环
最佳答案
shouldComponentUpdate
专门用于确定组件是否应该更新。做这样的事情:
if (nextState.counter == this.state.counter && nextProps.foo == this.Props.foo) {
return false;
}
componentWillReceiveProps
用于响应外部( Prop )更改。没有等效的componentWillReceiveState
,正如文档中指出的。您的组件(并且只有您的组件)通常通过以下一个或多个事件触发其自己的状态更改:
- 初始渲染于
getInitialState
- 更新了
componentWillReceiveProps
中的 Prop <input>
中的用户交互字段等,例如定制onChangeInput()
组件中的函数。- 不断变化:响应来自监听器的存储更改,通常在调用
getStateFromStores()
的自定义函数中,其中状态已更新。
我想在组件内使用一个函数来创建状态更改,然后在同一组件内使用另一个函数在状态更新之前进行干预是没有意义的。
在您的情况下,您可以将逻辑(以确定状态是否需要更新)移动到 getStateFromStores()
处理商店更新的函数。
或者,您可以简单地将其保留在状态中,并更改渲染函数,以便在 counter > 4 时呈现不同的效果。
关于reactjs - 可以从shouldComponentUpdate 中调用setState 吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33290189/