Hacker News Reader

Comment by davnicwil | Hacker News Reader

Whoah, hang on, really? Do you have a source on this or somewhere I can find out more details?

This will completey break a lot of libraries, components, etc that rely on the React lifecycle contracts.. Certainly doesn't feel like a small change! :-/

View on HN

Several relevant pointers:

- https://github.com/facebook/react/issues/7671

- https://twitter.com/dan_abramov/status/790590733468241920

- https://www.reddit.com/r/reactjs/comments/5fg7iq/why_should_...

- https://daveceddia.com/where-fetch-data-componentwillmount-v...

Also see Lin Clark's "React Fiber" talk, linked upthread. Basically, pieces of work can start and be interrupted, and then be restarted, which will mean that `componentWillMount` can be called several times before the component _actually_ mounts.

To be clear this is irrelevant to React 16 which works in sync mode for compatibility. We'll share more about any changes when we start enabling the async mode in Facebook products and figure out the best migration strategy.

Fortunately, componentWillMount is largely made redundant by the use of constructors.

Except it's not for when you actually want to know when the component was put into the DOM, or you're running react server-side

> when you actually want to know when the component was put into the DOM

You can use componentDidMount for that and its semantics are still the same.

Yes, componentDidMount is the place to work with DOM. componentWillMount never worked this way—it is basically a glorified constructor from pre-ES6 era.

Oh apologies - I really the comment as componentDidMount. My bad.

Reply on news.ycombinator.com