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

[probablyup]

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

[probablyup]

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

[probablyup]

@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

[aflanagan]

What if we needed or wanted to fire off a Redux action before the component mounts for the first time?

@nickzuber I was just coming to mention this. I work on a rails app that uses react-rails for server rendering a collection of smaller react/redux client apps. A pattern that is working well for us is to dispatch actions that populate our reducers with initial data in componentWillMount. That way you can easily pass data into your app from the rails view layer using react_component, and populate the state before rendering.

[sebmarkbage]

@ryanflorence This is more in response to Fiber and implementing componentWillUnmount.

For your use case, you don't really need componentWillUnmount since the use case is on the server anyway. You also don't need setState. So, technically you can still do the same thing in the constructor even though it is frowned upon. :) However, I think that for your use case a server-side-only componentDidMount might make the most sense (componentDidServerRender?). It would fire after rendering so it still requires two-passes but preserves the other capabilities.

[sebmarkbage]

@aflanagan Can you use the field initializer pattern (or constructor) that I used above to initialize the state from the props?

[aflanagan]

@sebmarkbage ah yes, I think we could do that. We adopted the cWM strategy before we moved to es6 classes, and I hadn't considered that we could start doing that in the constructor.

[probablyup]

To help tackle the server use case, what about a new method like componentDidRender? For the browser lifecycle, it'd come before cDM. The idea being the JSX has been rendered/"compiled" into vdom but not yet mounted somewhere.

[sebmarkbage]

There is one use case, that is also the same as the only use case for componentWillUpdate that I know about. Basically, you read some global mutable state so that you can reset it later in componentDidUpdate, after the children has already rendered.

For example, if the children rendering causes the scroll position of a page to change.

class ScrollRestore {
  componentWillMount() {
    this._scroll = Global.scrollTop;
  }
  componentDidMount() {
    Global.scrollTop = this._scroll;
  }
  componentWillUpdate() {
    this._scroll = Global.scrollTop;
  }
  componentDidUpdate() {
    Global.scrollTop = this._scroll;
  }
  ...
}

Technically, you can do the same thing in the constructor but it is kind of iffy to have impure constructors.

[mridgway]

Just wanted to chime in that componentWillMount causes a lot of confusion in the server-rendering and side-loading use cases where it seems like a good option but doesn't really work the way you expected since it's synchronous. I think the only use case that would have to be reconsidered with this deprecation is when you're still using React.createClass and don't have a convenient way to add to the constructor.

[ljharb]

Airbnb's primary use cases for componentWillMount are to seed our global translation singleton with phrases, which come from props, are needed in the render path, and are not necessarily available at construction time; and to bootstrap Alt stores with props.

All of our translations will break in the former case, if this lifecycle method is deprecated. Since we primarily handle phrases at the top level of a tree, ordering nondeterminism is not a concern for us.

In addition, constructors should never have side effects - componentWillMount provides us with an appropriate place to put side effects, that should basically only happen once per environment, that executes both on the client and server (componentDidMount, of course, would be for client-only).

[buildbreakdo]

Thought this GitHub search might be useful to see some use cases, sorted by recently indexed so it represents how people are actively using componentWillMount in the wild today.

Note: You must be logged in to search for code across all public repositories

https://github.com/search?l=javascript&o=desc&p=1&q=componentWillMount%28%29+language%3AJavaScript&ref=advsearch&s=indexed&type=Code&utf8=%E2%9C%93

[sebmarkbage]

@ljharb So, it's basically lazy initialization of global state. We do a lot of lazy initialization in render methods, but since it is generally unobserved I don't consider that bad practice. The difference here is that it is not just lazy but dependent on props.

I guess you assume that props will never change and that you won't ever have two different subtrees with different phrases. Otherwise, people normally use context for this use case.

Given that there are already a lot of assumptions involved in this particular use case, maybe it's not that bad to just do it in the constructor as a hack?

How do you do this server-side? Do you assume that the context is only used for a single request at a time? No async rendering?

[ljharb]

I'd very strongly prefer something besides the constructor. Hmm, I thought context was deprecated already :-p is it not?

Yes, that's right - whether it was async or not, it would be re-evaluated and reconstructed in a new vm for every request.

[ljharb]

If componentWillUpdate, or componentWillReceiveProps, or something similar, could be sure to run upon every new set of props, including the first/initial one, prior to the render - that would suffice for our use cases, I think, and would probably solve them more robustly than componentWillMount. Is adding a new lifecycle method out of the question?

[brigand]

Adding a consistent lifecycle method to handle props would be super useful in many cases. The most common being "fetch the x for this.props.xId". The benefit of running before render is that you can show a loading indicator without requiring a second render. The problem is that for some use cases you'd want it to run on the server, like @ljharb's, but for the fetching data you'd want that on only client in most cases.

Edit: maybe this should branch out to another issue.

[leebyron]

Is there ever a time (in the browser context) where componentWillMount is not called immediately after the constructor?

As far as I can remember, componentWillMount is effectively a constructor function. It served that purpose before ES6 classes were adopted that came with their own constructors. In fact, in much earlier versions of React, componentWillMount was _always_ called on construction IIRC which made server rendering painful. So we changed componentWillMount to be called only in the browser render context, and not in the server render context. (Then getInitialState was the effective constructor)

All the uses I've seen for componentWillMount are just constructors which you expect to only run in the browser. If componentDidMount isn't the right place to move that code (due to double render) then moving it into the class constructor with a typeof window if check might be adequate.

I don't see the reason to be concerned about doing side effects in a React component constructor if you're not concerned about doing the same within componentWillMount which is part of component construction. Since user code never instantiates components directly (library code does), the typical reasons to avoid side effect constructors doesn't apply for React components.

Sebastian, maybe another option is to slightly change the behavior of componentWillMount rather than remove it by making it more explicitly part of construction just to avoid user code writing that browser check and preserve the majority of existing code? Would that be possible within Fiber?

[bloodyowl]

I don't think I ever used componentWillMount for anything else than performing a setState(valueDerivedFromProps), which can be performed in constructor now.

The only blocker here would be that constructor isn't a React.createClass config field. For that matter, as there are differences between the React.createClass & the ES6 class-based APIs, I see three possibilities:

1. deprecate the React.createClass API completely (I don't know if it's planned for a foreseeable future)
2. introduce a new field in React.createClass that is consistent with the ES6 class constructor behaviour
3. keep the componentWillMount name only for React.createClass but change its behaviour to match constructor

---

@ryanflorence For the example in your codepen, you can just pass the extra context argument to the super function which will inject it in this.context (see in ReactComponent.js ) so that you can have access to this.context in the constructor:

class Widget extends React.Component {
  constructor(props, context) {
    super(props, context)
    this.context.register()
  }
  componentWillUnmount() {
    this.context.unregister()
  }
  render() {
    return React.Children.only(this.props.children)
  }
}

[michalwerner]

If there will be alternative do cWM to use in server rendering, then cWM deprecation seems fine. Something like componentWillServerRender, as said before, would be great.

[gaearon]

@leeb

All the uses I've seen for componentWillMount are just constructors which you expect to only run in the browser.

This doesn't sound right to me. componentWillMount, unlike componentDidMount, _does_ run on the server.

[ryanflorence]

@sebmarkbage @bloodyowl if I do work in the constructor, and the component never actually mounts, I still have the same problem as cWM, don't I? I have no chance to unregister. The problem for me is that I don't know before render if the thing will actually be rendered. Or, if it doesn't get rendered, I have no way of knowing it got aborted.

[mstijak]

If there are multiple inheritance levels, componentWillMount will execute after the object is fully constructed.

[necolas]

We use componentWillMount in 50+ components on mobile.twitter.com to:

• fetch data or report page impressions (most of this was in initial anticipation of full-page SSR)
• navigate to alternative pages (404, etc.) before assumed render
• get feature switch values that render depends on
• set initial state based on props

Most if not all of this looks like it could be done in the constructor or componentDidMount if necessary.

[sebmarkbage]

Some clarification: getInitialState (for createClass), constructor and componentWillMount always happen at the same time and have the same capabilities. The only difference is that componentWillMount can use this.setState where as the others have to return or initialize the state field.

Meaning, that technically you can do everything you can with getInitialState/constructor still. However, there is already a good understanding and practice that you don't do side-effects in those.

The reason to deprecate componentWillMount is because there is a lot of confusion about how it works, and what you can safely do in it, and usually the answer is _nothing_. It is a life-cycle with void return so the only thing you can do is side-effects, and it is very common to use them for things like subscriptions and data fetching without realizing the edge cases where it won't work out well.

The purpose would be to highly discourage side-effects, because they have unforeseen consequences, even though you technically could do them in the constructor.

That in turn, would help upgrading to something like Fiber without expecting a lot of race conditions to break your app in subtle way.

[sebmarkbage]

@ryanflorence You would feature test and only do that work in the constructor if you're on the server, and on the client you'd use componentDidMount. However, an explicit server-only componentDidServerRender would be better.

@mstijak We generally discourage deep inheritance. That's a design decision we've made due to complications like this one. Even if you do use it, it is common practice to not rely on super-classes calling back up to sub-classes for initialization purposes.

@michalwerner Would it be ok for the server-side only alternative to only fire after a component tree has rendered? I.e. semantically how componentDidMount works. Or do you rely on it being invoked early?

[ljharb]

@sebmarkbage On the server, the sole purpose is to produce HTML, so doing things after rendering seems pretty useless overall :-)

[sebmarkbage]

@ljharb The use case for @ryanflorence is to throw away the buffered HTML and do a redirect or render a different response based on what was rendered. This doesn't work with streaming necessarily but works well for async or parallelized/distributed rendering.

Another use case is logging components that were rendered but that doesn't have to be done before the HTML is produced.

[AlexGalays]

Only using it so I can avoid annoying constructors (it's more verbose, have to call super, etc) just to set the initial state

[ryanflorence]

@sebmarkbage we've got two use-cases 1) know there was a miss, but keep the HTML and use a 404 status, 2) throw away the HTML and redirect instead. In either case, as we discussed privately, we can do a two pass render for (1)

[istarkov]

The only use case for me for using componentWillMount is to avoid this error

Can only update a mounted or mounting component. This usually means you called setState() on an unmounted component

As in constructor state which depends on props should be defined without calling setState, but that state change code could be reused in other parts.

BTW I like the idea to remove componentWillMount as it has no advantages over the constructor but provide a lot of questions about how it differs.

[Rendez]

@sebmarkbage I think most of the cases can be solved by simply using the context to store whether or not the component will mount on the server. context.mountEnv. It would make it extremely simple. For airbnb's use case creating a HOC that defines childContextTypes = {mountEnv<string>} and does the init of translations and whatnot on the constructor would be enough. The Wrapped component can always be used to store statics if props alone is not enough to do this bootstrapping.

I can't think right now of something that cannot be done with constructor alone. I would probably start throwing a warning on the next version and deprecate it a bit later.

[rikutiira]

I have been using componentWillMount for a dependency library which wraps components in a HOC to load data dependencies both on client and server. It works by keeping track of all the loaded dependencies using promises and calling renderToString multiple times until there are no longer new dependencies to load.

But thinking on it now, componentWillMount should not be necessary for this. you could simply use constructor/getInitialState for calling the promises and then set state synchronously on next renderToString call once the dependencies have been loaded. Client can still use componentDidMount for setting the state.

I think it makes sense to deprecate componentWillMount, even from the point of isomorphic applications. I also don't think that it's necessary to add a componentDidServerRender method as you can easily code that logic yourself in the constructor.

[catmando]

@AlexGalays wrote: _Only using it so I can avoid annoying constructors (it's more verbose, have to call super, etc) just to set the initial state_ While this may not be the most important argument for keeping the componentWillMount, it is an important one.

[jkol36]

Can't you not call this.setState() in component will mount? Component will mount is only supposed to be for setting up listeners. Not to say, you can't do the same thing in ComponentDidMount but the main difference in my opinion is that setState() always works in componentDidMount() while it will not work in componentWillMount(). ComponentWillMount() and componentWillUnmount() have been perfect and explicit places to setup and tear down listeners without cluttering up componentDidMount() which often has other logic as well. Just my 2 cents.

[sebmarkbage]

@catmando @AlexGalays I think it would be more like a discouraging use, then a soft deprecation. A hard deprecation would take a long time and I'd expect that people would be using field initializers prevalently by then. They also let you avoid creating the super bloat of constructors.

@jkol36 That's not correct. setState() works in componentWillMount too which avoids a second pass to render.

[jkol36]

@sebmarkbage if you are right about that than I stand corrected. I do remember instances though where I would get an error saying something like "can't call setstate on mounting component" when trying to call setState() in componentWillMount()

[ryanflorence]

Is there anyway to know that a component rendered on the server w/ fibers? There is no cDM there, all we have is the constructor (or cWM) and we can't trust those.

My current approach is to send an object in and mutate it, check the object to see if we need to do a second pass render, and then use that object for the second pass to know what to render differently this time.

But as far as I can tell, there is no way to know something did or didn't render on the server.

[nightwolfz]

There's not a single componentWillMount in any of my projects, never understood why it was needed.

I just define static methods for fetching data on the server side over which I have full control and know exactly how and why they are called.

[vanluke]

generally I do not agree with componentDidMount. React lifecycle is like getDefaultProps, getIniitialState, componentWillMount, render, componentDidMount. And If you set state in componentDidMount you will rerender component, so render is called twice

[litinskii]

@sebmarkbage So for example if I use React.createClass and use componentWillMount to fetch same data and call setState() inside then better will be use getInitialState and do same inside getInitialState ?

[sericaia]

@w-site see componentDidMount docs

[gaearon]

then better will be use getInitialState and do same inside getInitialState ?

You can't use getInitialState for fetching data because it is synchronous.

[sompylasar]

Use case: componentWillMount contains dispatches of component-local data requests that are asynchronously fulfilled by corresponding redux-sagas. If the server-side rendering is enabled, the sagas run on the server-side until all asynchronous I/O in sagas is complete and no more re-renders are expected, and then the latest redux state and the latest rendered HTML is sent to the browser where it is rehydrated.

Example:

  componentWillMount() {
    const { isLoading, isLoaded, dispatch } = this.props;

    if (!isLoading && !isLoaded) {
      dispatch(makeAction(ACTION_FOO_LOAD_REQUESTED));
    }
  }

Refs Server-side rendering loop for universal sagas (redux-saga)

[jedwards1211]

So just to clarify, the current best practice for dispatching a redux action to fetch data or subscribe is in cDM on the client side and in the constructor on the server side?

[brigand]

@jedwards1211 on the server you fetch the data before rendering anything, put it in the redux store, and connect will pick it up for you.

[jedwards1211]

@brigand I understand a lot of people prefer to do that on the server side, but I prefer to use a component that subscribes on mount and unsubscribes on unmount, and use two-pass render on the server side to get the requests so that I can avoid having to write separate code to specify what data to fetch on the server side.

So again, if we've chosen to dispatch a redux action for any reason when a component mounts, the best place to do that on the server side is in the constructor?

[brigand]

@jedwards1211 Interesting. I'd write a high order component for it. Here's the concept. You'd define __SERVER__ with DefinePlugin in webpack.

[jedwards1211]

@brigand my thoughts exactly 😃 I've basically been doing the same, except I was using componentWillMount, so I'll just move that logic into the constructor. And to elaborate, on the client side I have middleware that handles the subscribe action by making a websocket RPC call. On the server side, I have middleware that just stores the subscribe actions in an array associated with the request. After the first render pass, I go through those actions and asynchronously fetch the initial data for them and dispatch it to the store. Then I render a second pass and send that to the client.

The multipass rendering isn't ideal, but I assume React will eventually provide the ability to efficiently update the virtual dom multiple times before actually rendering it to static markup, and keeping my subscription code DRY is well worth it to me.

[jamespedid]

I must be one of the few people to view having to use constructors instead of componentWillMount as a mistake. And this might just be a holdover from normal class idioms regarding keeping the constructor thin and never ever performing any operation inside of it that isn't needed to initialize the object to do any of the other things that it can be used for.

Here's a few arguments for why I would not use the constructor:

1. The constructor seems like it should be private to React, and just be an implementation detail. What if the signature of the constructor should need to change? Sure I can just blindly do super(...args), but I also see developers omit the second parameter of the constructor all the time, which to me seems like bad practice. Having the componentWillMount solves this.

2. It makes subclassing components more difficult. Now, I'm not the fan of inheritance in general, although I have found some usages for it that are appropriate already in the product. If the constructor is used here, then it may be that the constructor is doing too much in the parent component that cannot be erased in subclasses. Having the componentWillMount also solves this because I can choose to execute the super classes' version. (This might not be the best programming practice though, but that's not what's being argued here.)

3. It essentially makes unit testing of components more difficult because I can no longer just stub out the componentWillMount event if I don't want it to be called. This has proved to be fairly invaluable when testing certain other mounting operations when using enzyme without having to worry about actually making a call. And since this is typically done using redux to provide props, it usually can be done without problems.

If anything, I think that usage of constructors is what should be avoided, and not componentWillMount.

[jedwards1211]

@jamespedid you're saying you sometimes want to create an instance of a component without mounting it in your unit tests? So you can call some methods on it and test how those work?

[jamespedid]

@jedwards1211 That would be ideal, although I'm not sure how it works in the react world. I have used enzyme before, and it seems kind of silly to have to use a shallow wrapper and then grab the instance to be able to call methods on it, when I should just be able to new it up in general. I haven't investigated doing this though, and mostly just use Enzyme, although it wouldn't be hard to test.

[jedwards1211]

@jamespedid so then I don't understand what you mean by complaint no. 3 then. But I'm imagining there's probably a way to restructure your code that makes it easy to unit test without needing to monkeypatch componentWillMount with a noop.

If you're trying to test certain mounting operations perhaps you could just have your component call some standalone function with its props when it mounts, and then unit test that standalone function by itself? I would try to avoid monkeypatching a component I want to test, so that I test the totality of its behavior when it mounts.

[tekacs]

Carrying on from @mstijak and @jamespedid I'd again emphasise that whilst you may discourage 'deep inheritance' (according to @sebmarkbage), it's pretty useful/important to be able to run something after all construction but before mounting, in the sense that (this is TypeScript):

// This is sanitised production code, sorry if the use case seems obscured.
abstract class BaseComponent<P> extends React.Component<P, {}> {
  abstract key$: rx.Observable<string>

  props$: rx.BehaviorSubject<P>
  selected$: rx.Observable<any>

  componentWillMount() {
    this.props$ = new rx.BehaviorSubject(this.props)
    this.selected$ = rx.Observable
      .combineLatest(this.props$, this.key$)
      .map(([props, key]) => props[key])
  }

  componentWillReceiveProps(nextProps: P) {
    this.props$.next(nextProps)
  }
}

class ConcreteComponent extends BaseComponent<{}> {
  key$ = rx.Observable.of("name") // This actually changes in practice.
}

Note that BaseComponent can't perform the initialization inside of its constructor, as that runs before child constructors are run (because the child constructor initializes key$)

The initialization can't be run inside componentDidMount because the initial render needs to use the properties that are set here (note that this isn't async and so will be ready before render()).

This is one level of inheritance (and we don't go deeper). The alternative that lets you factor out the common parts from a component would be mixins, I guess? Another way to do this might be to pass every such value up from the child using extra constructor parameters (this works, but is pretty unergonomic (remember to pass context!) and requires the parent to initialize the this.XXX fields).

So in summary, this pattern is stable, works correctly as-is and doesn't appear to have a pleasant substitute AFAICT. Happy to be corrected.

[jedwards1211]

@tekacs Yo dawg, I heard you like reactive programming
...so I put your props into an RxJS stream so that you could get reactive updates when you get reactive updates
:wink:

[tekacs]

@jedwards1211 That's just to build a render$ observable from many other observables combined with props$, rather than having to handle the latter specially.

But yes, I take a component being reactively updated as a whole and reactively update it from the inside. The result comes out pretty nicely despite that silliness. 😆

render$ = obs.combineLatest(this.props$, this.data$, this.ready$).map(([props, data, ready]) => ...)

[jedwards1211]

@tekacs as in, you're passing in some data as props and some from observables that take the place Redux, etc. would?

[sebmarkbage]

There's a use case that I find compelling. E.g. you want to trigger an async data request now because you know you'll need it soon but first you'll want to render your child content. Kind of like the link prefetch in browser. However, you don't necessarily need a handle on and instance to do that.

It might be enough to have a static method without access to this nor state.

static componentWillMount(props, context) { }

[ljharb]

Without access to state, how would you store the result of the async request?

[sebmarkbage]

You would rely on an external system to keep its cache around. Like Relay or some Flux store. So when you request it again, it's available. Just like when you <link rel="prefetch" /> something you don't get a direct handle on the resource. A separate request gets the data.

Note that this use case is not meant to be used as a canonical data loading model. That can have an async API that builds on the ideas in #8595. That would explicitly block further rendering on this subtree until data is fetched. You could combine these so that componentWillMount prefetches, you render some API and then after an update, you block on async.

[jedwards1211]

@tekacs In any case, I think there are any number of ways you could avoid deepening the class hierarchy and still accomplish what you want to do. For example:

function createRxJSComponent({key$, methods}: {key$: rx.Observable<string>, methods?: Object}): ReactClass<P> {
  class RxJSComponent extends React.Component<P, {}> {
    props$: rx.BehaviorSubject<P>
    selected$: rx.Observable<any>

    componentWillMount() {
      if (methods && methods.componentWillMount) methods.componentWillMount()
      this.props$ = new rx.BehaviorSubject(this.props)
      this.selected$ = rx.Observable
        .combineLatest(this.props$, key$)
        .map(([props, key]) => props[key])
    }

    componentWillReceiveProps(nextProps: P) {
      if (methods && methods.componentWillReceiveProps) methods.componentWillReceiveProps(nextProps)
      this.props$.next(nextProps)
    }
  }

  for (let key in methods) {
     if (!RxJSComponent[key]) RxJSComponent[key] = methods[key]
  }

  return RxJSComponent
}

const ConcreteComponent = createRxJSComponent({
  key$: rx.Observable.of("name") // This actually changes in practice.
})

[tekacs]

@jedwards1211 Yup props$ + several other state streams, which include observable GraphQL queries (via Apollo), a state store and others (such as Subjects passed down to children to propagate back up, rather than the messier pattern of passing onSomething functions).

What you suggest in your last post certainly works (I've certainly thought of it), only I'm using abstract classes to make it easy for downstream implementors on my team to:

a) Implement the component correctly and
b) Access and override a variety of common functionality used by many components of that kind.

Perhaps it makes it less clear that I chose the simplest example I could find in my post to reduce things down, but I assure you the result turns out unmanageably messy and huge if done using a pattern like the above. :confused:

An actual base component looks more like this (I wrote this in a few hours just recently to get something core sorted and it has 10+ subclasses):

https://gist.github.com/tekacs/d7f961479bd15cc238ce35dfb11fa403

Whilst it's certainly possible to transform this into the form you give above, it's not nearly as practical.

[paynecodes]

My use case for componentWillMount():

class Example extends React.PureComponent {
  componentWillMount() {
    const { fetchAction, fetchStatus, dispatch } = this.props;
    if (fetchStatus !== FETCH_STATUSES.LOADING && fetchStatus !== FETCH_STATUSES.LOADED) {
      dispatch(fetchAction);
    }
  }

  render() { ... }
}

If another component renders multiple Example components, dispatch(fetchAction) only happens once as expected. If the Example component utilizes componentDidMount(), dispatch(fetchAction) is called twice. Perhaps there is a better way?

I apologize if this has already been covered. I skimmed comments that didn't seem completely relevant.

[ljharb]

@jpdesigndev i'm not sure why it would be; componentDidMount is only ever called once just like componentWillMount?

[paynecodes]

Sorry, @ljharb, I wasn't clear enough.

const SomeParent = (props) =>
  <div>
    <Example />
    <Example />
  </div>

If SomeParent component renders the Example component, twice (real use case, I apologize for the generic examples), componentDidMount() will result to dispatching the actions twice, while componentWillMount() results in the action being dispatched only once (expected). I'm certain there is a perfectly reasonable explanation for this (sync/async, or some other timing reason), but this is why I prefer to do this conditional data fetching in componentWillMount() for the time being. Perhaps this is an anti-pattern? Perhaps someone will suggest that I move data fetching up to the parent (this would break a nice encapsulation)?

---

EDIT: for clarity (hopefully)

class Example extends React.PureComponent {
  componentWillMount() {
    const { fetchAction, fetchStatus, dispatch } = this.props;
    //
    // Notice the conditional here.
    // If this code were in a componentDidMount(), the fetchStatus would be null
    // for both <Example /> renders by <SomeParent />
    //
    // By utilizing componentWillMount()
    // The second componentWillMount() call has the new fetchStatus
    // that was updated synchronously by the dispatched action from the first <Example />
    // rendered by <SomeParent />
    if (fetchStatus !== FETCH_STATUSES.LOADING && fetchStatus !== FETCH_STATUSES.LOADED) {
      dispatch(fetchAction);
    }
  }

  render() { ... }
}

const SomeParent = (props) =>
  <div>
    <Example />
    <Example />
  </div>

[ljharb]

That makes no sense to me - two elements should invoke two WillMounts.

[sompylasar]

@jpdesigndev I would suggest to move data fetching away from components, keeping only data fetching request dispatching in them. See redux-saga.

[sompylasar]

@jpdesigndev Sorry I meant the logic for checking if the fetch is in progress and ignoring the request.

[acdlite]

@jpdesigndev In your example, the difference is that in componentWillMount, this.props points to the next props that haven't rendered yet. Whereas in componentDidMount, they point to the props that just rendered. This is because didMount fires during React's "commit phase." When you call setState inside didMount, React doesn't apply the update until the end of the current commit phase. So even though you've fired dispatch in the first didMount, that update hasn't been applied yet by the time you call the second didMount.

One solution would be read the FETCH_STATUS directly from the store, since that is mutated synchronously upon dispatch. Rather than rely on React props/state, which are updated asynchronously.

[paynecodes]

@ljharb @sompylasar @acdlite Thank you all for the thoughts/recommendations!

@sompylasar Leaving this logic at the component level can, sometimes, make sense. For example, if the component really should be in control of fetch/re-fetch. Without some force param on the action creator, it's simple enough to just conditionally call fetch in the component instead of the Action Creator / saga / observable (epic) controlling when to fetch.

@acdlite Thank you for the explanation. That really helps clarify my thoughts on why *WillMount works better here vs. *DidMount. I'm not sure I love/understand the idea of reading from the store directly in this case. In fact, this is a connected component that utilizes selectors to get at the fetchStatus from props.

I'm really just chiming in here to lay out a use case (which seems valid) for componentWillMount(). I'm still not convinced there is a better way.

Thus far the proposed better/alternative ways are:

1. Delegate control to Action Creators or Side Effect middleware
2. Read fetchStatus directly from the store instead of relying on props

I'm perfectly willing to change my mind on this. Perhaps, I will be forced to do so if componentWillMount() is deprecated. Do folks agree that either of these approaches are more desirable than my componentWillMount() example?

Also, have I missed the point entirely? Should I already be devising a way to migrate away from componentWillMount()?

[sompylasar]

@sompylasar Leaving this logic at the component level can, sometimes, make sense. For example, if the component really should be in control of fetch/re-fetch. Without some force param on the action creator, it's simple enough to just conditionally call fetch in the component instead of the Action Creator / saga / observable (epic) controlling when to fetch.

@jpdesigndev Then you have two actions: "fetch" (that leads to auto-cache and no re-fetch) and "refetch" (that leads to resetting the cache, stopping all previous requests, and re-fetching).

[bvaughn]

componentDidServerRender now has an RFC reactjs/rfcs/pull/8 😄

[NE-SmallTown]

@sebmarkbage

The purpose would be to highly discourage side-effects, because they have unforeseen consequences, even though you technically could do them in the constructor.

Could you give more details about this? Is there any edge case?

[TrySound]

@NE-SmallTown Take a look at link above