Deprecate componentWillMount Maybe?

[sebmarkbage]

Let's use this thread to discuss use cases for componentWillMount and alternative solutions to those problems. Generally the solution is simply to use componentDidMount and two pass rendering if necessary.

There are several problems with doing global side-effects in the "componentWill" phase. That includes starting network requests or subscribing to Flux stores etc.

1. It is confusing when used with error boundaries because currently componentWillUnmount can be called without componentDidMount ever being called. componentWill* is a false promise until all the children have successfully completed. Currently, this only applies when error boundaries are used but we'll probably want to revert this decision and simply not call componentWillUnmount here.

2. The Fiber experiment doesn't really have a good way to call componentWillUnmount when a new render gets aborted because a higher priority update interrupted it. Similarly, our sister project ComponentKit does reconciliation in threads where it is not safe to perform side-effects yet.

3. Callbacks from componentWillMount that update parent components with a setState is completely unsupported and lead to strange and order dependent race conditions. We already know that we want to deprecate that pattern.

4. The reconciliation order of children can easily be dependent upon if you perform global side-effects in componentWillMount. They're already not fully guaranteed because updates can cause unexpected reconciliation orders. Relying on order also limits future use cases such as async or streaming rendering and parallelized rendering.

The only legit use case for componentWillMount is to call this.setState on yourself. Even then you never really need it since you can just initialize your initial state to whatever you had. We only really kept it around for a very specific use case:

class Foo {
  state = { data: null };
  // ANTI-PATTERN
  componentWillMount() {
    this._subscription = GlobalStore.getFromCacheOrFetch(data => this.setState({ data: data });
  }
  componentWillUnmount() {
    if (this._subscription) {
      GlobalStore.cancel(this._subscription);
    }
  }
  ...
}

When the same callback can be used both synchronously and asynchronously it is convenient to avoid an extra rerender if data is already available.

The solution is to split this API out into a synchronous version and an asynchronous version.

class Foo {
  state = { data: GlobalStore.getFromCacheOrNull() };
  componentDidMount() {
    if (!this.state.data) {
      this._subscription = GlobalStore.fetch(data => this.setState({ data: data });
    }
  }
  componentWillUnmount() {
    if (this._subscription) {
      GlobalStore.cancel(this._subscription);
    }
  }
  ...
}

This guarantees that the side-effect only happens if the component successfully mounts. If the async side-effect is needed, then a two-pass rendering is needed regardless.

I'd argue that it is not too much boilerplate since you need a componentWillUnmount anyway. This can all be hidden inside a Higher-Order Component.

Global side-effects in componentWillReceiveProps and componentWillUpdate are also bad since they're not guaranteed to complete. Due to aborts or errors. You should prefer componentDidUpdate when possible. However, they will likely remain in some form even if their use case is constrained. They're also not nearly as bad since they will still get their componentWillUnmount invoked for cleanup.

[quantizor]

I mostly use cWM to perform setState based on initial props, since cWRP doesn't fire initially. I could do it in constructor, but I try and avoid extending that method when possible because I have an allergy to super calls :/

[sebmarkbage]

@yaycmyk If you could use field initializers would you use that instead?

class Foo {
  state = { data: this.props.initialData };
  ...
}

or for something more complicated:

class Foo {
  state = this.computeInitialState();
  computeInitialState() {
    var state = { data: null};
    if (this.props.something) {
      state.data = this.props.somethingElse;
    }
    return state;
  }
  ...
}

[jquense]

for createClass cWM is the only place to do constructor stuff, since you can't actually define a constructor. I need to do a grep through some of our code bases I think there are a couple other use cases/optimizations that use it I'm not remembering

[quantizor]

@sebmarkbage I do use property intializers, though they become clumsy if you need a non-trivial amount of Boolean logic. To be fair, they do cover 95% of all my use cases. cWM is a rare sighting in our products

[mars]

For server rendering, componentWillMount fires but not componentDidMount.

What would replace the browser-only nature of componentDidMount? Adding if (typeof window === 'undefined') expressions to detect render mode in componentDidMount seems dirty compared to the current lifecycle function approach.

[sebmarkbage]

@mars componentDidMount would still only fire on the client. Do you have a use case in mind for componentWillMount on the server?

[petehunt]

I only use it to set up data structures on this for things like memoization, but with ES6 class constructors there's no reason for it anymore.

[mars]

After looking back at my last app that used server-rendering, the only componentWillMount use case is an initial setState. So, following @sebmarkbage's suggestion to conditionally setState in componentDidMount would be a fine way to allow deprecation of componentWillMount.

[ryanflorence]

This issue is probably because of some of my recent hackery. Today, given that when componentWillMount is called you can actually trust that it will be mounted, you can do stuff like register descendants with an ancestor and use that information in render in another ancestor.

http://codepen.io/anon/pen/gwbEJy?editors=0010

As a sort of DOM parallel, when you have a form that has two inputs where one of them is a button, then "keyDown" of a text input causes the form to submit. In other words, the presence or non-presence of another ancestor changes the behavior of another ancestor element. Also, radio groups.

Not saying "keep componentWillMount" but it's a great way to create relationships between ancestors of a context. It would be nice to either 1) have a componentMountCancelled (sounds unlikely, or 2) call cDM on the server (???) because that's the only reason I do this in cWM or 3) have some first class API for building this kind of relationship between ancestors in the same context.

I'd like (3), but have no idea what that looks like.

For the use-case here, it's in the React Router v4 API:

<div>
  <Match pattern="/users" component={Users}/>
  <Match pattern="/about" component={About}/>
  <Miss component={NoMatch}/>
</div>

If no <Match/> matches the location, then the descendant <Miss/> components in context will be rendered (and it's beautiful, isn't it?!)

Only reason this matters is server rendering. Thanks to some talks with @sebmarkbage we've got a plan B, but I am a little 😢 about this. (I think we might get a flicker when we move to cDM ... which is not exciting.)

I'm pretty sure @kenwheeler's new <Song> employs this technique also, but could probably move to cDM.

[quantizor]

@ryanflorence Why not just extend constructor in that case though? cDM is really a last resort since it's way less efficient from needing a second render pass.

[nickzuber]

Would there ever be a case where we'd need to compute some data or perform a certain routine before the component mounts, that we otherwise wouldn't be able to do in the component constructor?

What if we needed or wanted to fire off a Redux action before the component mounts for the first time? Or what about wanting to attach an event listener to the component before it mounts?

I'm just worried that there might be some niche use cases for componentWillMount that we aren't thinking of here.

@ajwhite I'm curious what you think about this