Component life-cycle methods for update

[syranide]

getInitialState
componentWillMount (setState is applied without side-effects)
componentDidMount (setState causes an update)

All good, everything makes sense for mounting.

componentWillReceiveProps (setState is applied without side-effects)
shouldComponentUpdate
componentWillUpdate (setState is disallowed)
componentDidUpdate (setState causes an update)

If you need to update state and it isn't based on the new props, there is no place to do it it seems. Sure, you can stick it in componentWillReceiveProps, but that puts it before shouldComponentUpdate which is bad. componentWillUpdate seems like the obvious choice but it's not allowed, is there a good reason for this or is it "because you shouldn't"?

Personally, I don't think there are very many reasons to call setState from componentWillUpdate, but I have encountered a scenario or two where I would like to call setState after shouldComponentUpdate (i.e. in componentWIllUpdate).

[sophiebits]

Can you give an example of when you want this? The idea is that shouldComponentUpdate should be able to look at the state to determine whether to update.

[syranide]

Generally it seems to me that you want this for the same reasons you would want to call setState in componentWillMount (getInitialState = componentWillReceiveProps, componentWillMount = componentWillUpdate IMHO). Storing results from side-effects, caching too expensive computations, etc. setTimeout is a "common" problem, you want to store the ID so it can be cancelled, right now you "have" to store it outside of state.

The times I've encountered this so far are the above, especially dealing with the result of setTimeout and external side-effects (measuring some other DOM, in my case for overlaying things on an iframe).

[sophiebits]

Timeout IDs should be stored outside of state. State is for things that (might) affect render. Presumably the state change needs to be triggered by something, and currently doing a state change in response to a props change is supported. If you can make state changes in componentWillUpdate after shouldComponentUpdate returns true, is there no way to skip the render at that point or are you proposing running shouldComponentUpdate again?

More specific use cases would help me understand you here.

[syranide]

Timeout IDs should be stored outside of state. State is for things that (might) affect render.

Are you "sure"? I was under the impression that it belongs in state from older "overheard" discussions (and modifying this seems dirty), because in a way, a timeout ID is an indication that something is happening (and in the case of XHR/etc they hold additional information). It doesn't sound very alien to me to want to show some visual indication for whatever the timeout is doing (searching, etc), using a separate property for indicating that is another potential for inconsistency (and technically redundant). I may very well be wrong, but that's how I have understood it.

Presumably the state change needs to be triggered by something, and currently doing a state change in response to a props change is supported.

Right, it will always be triggered by prop/state change, but the prop/state change could have external side-effects or have changed because of external events. componentWillReceiveProps is to me the equivalent of getInitialState, both can set state based on props.

But if props are the only source of information for state, then there should be no reason to call setState from componentWillMount? If there is a reason for it, then it seems logical that you could do the same in componentWillUpdate, the only difference between mount and update is technically whether or not it is the initial rendering, right?

If you can make state changes in componentWillUpdate after shouldComponentUpdate returns true, is there no way to skip the render at that point or are you proposing running shouldComponentUpdate again?

My thoughts were simply that they're applied just like they are in componentWillMount, immediately, no side-effects, nothing. You cannot abort componentWillMount so there's no reason you should abort componentWillUpdate.

I see setState in componentWillMount and componentWillUpdate as a way to update state with additional data from external sources or from performed actions. If you have costly computations (or say external DOM interaction) that you want to cache then componentWillUpdate is the only place that makes to make sense to me I think, as it should happen after shouldComponentUpdate.

More specific use cases would help me understand you here.

Definitely, but it's a bit tricky, my use-cases so far are mostly rather special components with external interaction (editor-related stuff). So it's not everyday stuff, and I think that's also why I seem to need it. For ordinary components, state based on props/user input is the answer to everything basically and componentWillReceiveProps is enough. But for non-ordinary it's not enough.

Also, it's largely because I see the following connection as I've mentioned:

getInitialState => componentWillReceiveProps
(always true) => shouldComponentUpdate
componentWillMount => componentWillUpdate
componentDidMount => componentDidUpdate

The only thing that's behaviorally inconsistent (for setting state) according to that is componentWillMount and componentWillUpdate for some reason?

Anyway, I'm a little overburdened at the moment, but I'll try to boil down my use-cases to something more tangible (and think them over once more).

[sophiebits]

We were considering disallowing setState in componentWillMount in favor of just having people use getInitialState.

[syranide]

Interesting, but I feel like it excessively punishes people who don't use Flux or a "great big model", for no good reason. Dispatching requests/timers/etc seems to makes sense in componentWillMount and componentWillUpdate when you don't have ab external model to take care of it.

[sophiebits]

If the data isn't easily available synchronously, you can just use componentDidMount.

[syranide]

Even if it is available synchronously, doing complex not-strictly-prop-based state updates from getIniitialState and componentWillReceiveProps seems dirty. Same for dispatching requests/timers, from getInitialState? That doesn't seem sane.

[sophiebits]

As I understand it, requests should be sent and timers set in componentDidMount.

[syranide]

React.createClass({
  ...
  componentDidMount: function() {
    if (this.props.searchText !== this.state.searchedForText) {
      var R = dispatchRequest(...);
      // what to do with R
      this.setState({
        searchedForText: this.props.searchText,
        searching: true
      });
    }
  },
  ...
});

Seems like a significant downgrade from simply using componentWillMount, it now requires two renders rather than just one. Or am I missing something obvious?

[gaearon]

I'm closing as outdated, if there is more to discuss let's do it in #7678.