从shouldComponentUpdate内调用setState可以吗? [英] Is it OK to call setState from within shouldComponentUpdate?

查看:787
本文介绍了从shouldComponentUpdate内调用setState可以吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

为响应状态更改,我想触发另一个状态更改.这天生是个坏主意吗?

In response to a state change, I want to trigger another state change. Is that inherently a bad idea?

特定类型的场景是将该组件建模为状态机,该状态机根据this.state.current_state的值呈现不同的信息.但是外部事件可以通过通量存储更改其状态,从而促使其经历状态转换.这是一种可让您理解该想法的方案:

The specific sort of scenario is that the component is modeled as a state machine that renders different information according to the value of this.state.current_state. But external events can prompt it to experience a state transition, via changes to it's state through a flux store. Here's a contrived scenario to get the idea across:

我认为正确的生命周期方法是shouldComponentUpdate.达到这种效果的方法:

I think the correct lifecycle method to do this would be shouldComponentUpdate. Something to this effect:

shouldComponentUpdate: function(nextProps, nextState) {
    if (nextState.counter > 4 && this.state.current_state !== DISPLAY_MANY) {
        this.setState({ current_state: DISPLAY_MANY });
    }
    return true;
}

在某些子组件中,counter可能会增加,因此,我不想根据某些counter变量的值推断其显示内容,而是想对状态进行显式编码.

In some child component, counter may get incremented, so rather than inferring what it would display based on the value of some counter variable, I'd like to encode the states explicitly.

实际场景比这要复杂得多,但希望此场景足够详细,可以使您理解.可以做我想做的事吗?

The real scenario is more complicated than this, but hopefully this scenario is detailed enough to get the idea across. Is it OK to do what I'm thinking?

固定代码示例,通过添加额外的状态条件来避免触发无限循环

fixed code example to avoid triggering infinite loop by adding extra state condition

推荐答案

shouldComponentUpdate专门用于确定组件是否应该完全更新.做类似的事情:

shouldComponentUpdate is intended specifically to determine if the component should update at all. To do things like:

if (nextState.counter == this.state.counter && nextProps.foo == this.Props.foo) {
  return false;
}

componentWillReceiveProps用于响应外部(道具)的更改.如文档中所指出的,没有等效的componentWillReceiveState.您的组件(并且只有您的组件)通常通过以下一个或多个事件来触发其自身的状态更改:

componentWillReceiveProps is for responding to external (props) changes. There is no equivalent componentWillReceiveState, as pointed out in the docs. Your component (and only your component) triggers it own state changes, usually through one or more of the following events:

  • getInitialState
  • 中的初始渲染
  • componentWillReceiveProps
  • 中的更新道具 <input>字段中的
  • 用户交互等,例如在组件的自定义onChangeInput()函数中.
  • 不断变化:响应来自侦听器的存储更改,通常在调用状态为更新的自定义函数getStateFromStores()中进行.
  • initial rendering in getInitialState
  • updated props in componentWillReceiveProps
  • user interaction in <input> fields etc, e.g. in custom onChangeInput() functions in your component.
  • in flux: responding to store changes from listeners, typically in custom functions calling getStateFromStores(), where state is updated.

我想在组件内部使用一个功能来创建状态更改,然后在状态更新之前干预该组件内部的另一个功能是没有道理的.

在您的情况下,您可以将逻辑(以确定状态是否需要更新)移动到用于处理商店更新的getStateFromStores()函数.
或者,您可以简单地使其保持状态,并更改渲染功能,以便在counter> 4时,其渲染方式有所不同.

In your case, you could move the logic (to determine if state needs to be updated) to a getStateFromStores() function where you handle store updates.
Or, you could simply leave it in state, and change your render function, so that it renders differently if counter > 4.

这篇关于从shouldComponentUpdate内调用setState可以吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆