5 ms·
Is this as big a change as Angular 2 for you react devs?
by xeromal 10y ago
Is this as big a change as Angular 2 for you react devs?
- cprecioso 10y agoNo, this is mostly an internal change, the API is not changing.
- xeromal 10y agoThanks.
- vmasto 10y agoSome 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.
- davnicwil 10y agoWhoah, 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! :-/
- acemarke 10y agoSeveral relevant pointers: - https://github.com/facebook/react/issues/7671 https://github.com/facebook/react/issues/7671 - https://twitter.com/dan_abramov/status/790590733468241920 https://twitter.com/dan_abramov/status/790590733468241920 - https://www.reddit.com/r/reactjs/comments/5fg7iq/why_should_ajax_requests_go_in_componentdidmount/ https://www.reddit.com/r/reactjs/comments/5fg7iq/why_should_... - https://daveceddia.com/where-fetch-data-componentwillmount-vs-componentdidmount/ 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.
- danabramov 10y agoTo 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.
- lobster_johnson 10y agoFortunately, componentWillMount is largely made redundant by the use of constructors.
- madeofpalk 10y agoExcept 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
- wayfarer2s 10y ago> 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.
- danabramov 10y agoYes, componentDidMount is the place to work with DOM. componentWillMount never worked this way—it is basically a glorified constructor from pre-ES6 era.
- madeofpalk 10y agoOh apologies - I really the comment as componentDidMount. My bad.
- oakesm9 10y agoNot 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.
- danabramov 10y agoPlease 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.
- schmrz 10y agoMost likely not, as it's supposed to be backwards compatible.
- zackify 10y agoNot 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.