Re: Developer Tools Team React 16 upgrade

[Patrick Brosset]

Thank you Mike for the huge piece of work. Also thank you to the code
reviewers and people who helped make this happen.
This was indeed very much worth the time, considering the performance gains.

Cross-posting to the devtools mailing list too.

On Tue, Mar 13, 2018 at 2:31 PM, Michael (work) <mratc...@mozilla.com>
wrote:

> A few weeks back the Developer Tools team upgraded from React 15.6.1 to
> React 16.2.0.
>
> To complete this upgrade we had to make a large number of changes to many
> of our Developer Tools. There was a decent amount of work we had to do
> across all of our GitHub repos but the majority of the work can be seen in
> this dependency graph:
> https://bugzilla.mozilla.org/showdependencytree.cgi?id=
> 1416824&hide_resolved=0
>
> We have both the production and development versions of React but the
> development versions are only used, or exist, when `ac_add_options
> --enable-debug-js-modules` is set in `.mozconfig` or at least that will be
> the case when https://bugzil.la/1440609 lands.
>
> *React worked fine before so why the upgrade?*
>
> The speed increases we have seen as a result of the React upgrade have
> been impressive averaging around 6-7% speed increase in reported by our
> DAMP tests and up to 30% increase in some tools!
>
> If you add to this that many of the speed increases in React 16 are
> perceived performance it is obvious that user's speed increase perception
> is going to be much higher.
>
> The React team have managed to accomplish this by completely rewriting
> their rendering engine so that it now chooses paths, called fibres, through
> the render tree and will hold off refreshing branches of the tree if it
> would otherwise be rendered multiple times.
>
> Another thing that makes things faster is that React now makes good use of
> the requestIdleCallback API to ensure that components are only rendered
> when the browser is not busy.
>
> Because React is now using this method we are ready for the next big
> change, which Dan Abramov spoke about in JSConf Ireland 2018:
> https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html
>
> He explains it clearly:
>
> "We’ve built a generic way for components to suspend rendering while they
> load async data, which we call suspense. You can pause any state update
> until the data is ready, and you can add async loading to any component
> deep in the tree without plumbing all the props and state through your app
> and hoisting the logic.
>
> On a fast network, updates appear very fluid and instantaneous without a
> jarring cascade of spinners that appear and disappear. On a slow network,
> you can intentionally design which loading states the user should see and
> how granular or coarse they should be, instead of showing spinners based on
> how the code is written. The app stays responsive throughout."
>
> So in a nutshell, we will be able to add a property to components that
> allow them to render asynchronously. This could potentially result in even
> higher performance increases... watch this space.
>
> /Mike Ratcliffe
>
> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>