Hacker News Reader

Comment by xeromal | Hacker News Reader

Is this as big a change as Angular 2 for you react devs?

Not at all, nothing incompatible changes on the surface. There are more features and no breaking changes. It's mostly all under the hood!

There will be new public api's to build your own custom rendering engine, ex how there is react-dom for browsers, react-native for mobile, and it will get easier to target new platforms thanks to fiber.

Thanks.

For those who have side-effects in their component lifecycle methods might have some problems when they turn on async fibers.

Which, in Facebook's defense, they've explicitly and often warned against

This will not be default until React 17 I believe.

Most likely not, as it's supposed to be backwards compatible.

No, this is mostly an internal change, the API is not changing.

Some of the API semantics are changing, e.g. componentWillMount can't be trusted any more (it can fire many times) but they're going to be pretty small.

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

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.

Not in terms of it being a breaking change. It's meant to be a big speed improvement but the API is largely the same I believe.

Please note that Fiber is not meant to be a “big speed improvement”. (React is already pretty fast, and most speed improvements you can do in this space are marginal for most apps.)

Fiber is a rewrite that makes it easier for us to add new features to React (and it adds some). It also adds the foundation for enabling better perceived performance in the future releases thanks to async pre-rendering and more control over scheduling. That part is still work in progress and won't be enabled in React 16 by default.

So we do think eventually it’ll enable us to build more responsive apps, but we’re still working out the details and experimenting with what it can do. Don’t expect any drastic changes on this front in React 16.

Reply on news.ycombinator.com