Is it OK to call setState from within shouldComponentUpdate?

Question

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

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:

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;
}

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?

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

Answer 1

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 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:

• 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.

I guess it doesn't make sense to have one function inside a component to create a state change, and then another function inside the same component to intervene before state is updated..

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.

Answer 2

No. Please use componentWillReceiveProps instead. It has the same signature of shouldComponentUpdate and you're safe to call this.setState there.