[Fresh] Track mounted roots via DevTools Hook

[gaearon]

The previous Fresh runtime API forced you to pass a root handle. However, that presumes that the module runtime (such as Metro) somehow is aware of all roots on the page. This isn't the case.

We could have React keep track of mounted roots. However, that might not be necessary. Here's why.

We still need some way to let the module runtime schedule refreshes. Currently this is done via DevTools Global Hook injection. DevTools (or module runtime) can set up the Global Hook. The renderer injects scheduleHotUpdate in it. As a result, the module runtime can schedule refreshes.

Since we already rely on the DevTools Hook for communication, we might as well use the fact that this Hook gives us information about all roots. Indeed, that's how DevTools itself works.

The Goal

This PR lets the module runtime do

ReactRefreshRuntime.injectIntoGlobalHook(window);

and then

ReactRefreshRuntime.performReactRefresh(update);

without worrying about how to track mounted roots.

Implementation

Adding injectIntoGlobalHook to Refresh Runtime

• This either sets up a shimmed tiny version of the Global Hook (for web users without extension).
• Or, if the Global Hook is already set up (for web users with extension, or for RN which always sets it up), monkeypatches it.

The goal in both cases is to grab the scheduling functionality and to track roots in the Runtime. This lets the module system (e.g. Metro) simply call ReactRefreshRuntime.performReactRefresh() and not worry about how this connects to React.

The only constraint is that ReactRefreshRuntime.injectIntoGlobalHook() needs to run before the renderer code. The module system can guarantee it because it owns the execution order.

I have added regression tests for tracking roots.

Tweaking the API exposed to DevTools

Previously, we had scheduleHotUpdate(root, update) which included the resolution function. However, I realized this doesn't really work if you don't have a root. For example, if you hot update a component, but no roots are mounted yet, you still want its next render to use the updated version. So you need to inject the resolution function anyway.

I changed the API to:

• setRefreshHandler(handler) — This sets up the family resolution function. It is called on first edit even if there are no roots.
• scheduleRefresh(root, update) — renamed from scheduleHotReload
• findHostInstancesForRefresh — renamed from findHostInstancesForHotReload

Follow-ups

There's a few things I plan to change here later. One is to use host config for getting client rect. But this isn't critical to get in now, since I don't plan to implement this in the first Metro integration. The second one is to add a few convenience helpers to move more React-related logic out of the module runtime (e.g. Metro). I might push that a bit later but it doesn't block this PR.

[sizebot]

Details of bundled changes.

Comparing: 9845437...d20de50

react-refresh

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
react-refresh-runtime.development.js	+146.2%	+113.8%	6.8 KB	16.74 KB	2.46 KB	5.25 KB	NODE_DEV
react-refresh-runtime.production.min.js	-27.3%	-55.4%	1.93 KB	1.4 KB	1009 B	450 B	NODE_PROD
react-refresh-babel.development.js	0.0%	-0.1%	21.67 KB	21.67 KB	4.65 KB	4.65 KB	NODE_DEV
react-refresh-babel.production.min.js	0.0%	-0.2%	6.3 KB	6.3 KB	2.17 KB	2.16 KB	NODE_PROD

Generated by 🚫 dangerJS

[gaearon]

Pushed a second commit. This just adds some helpers that are currently inlined in Metro in my draft. It doesn't make sense to inline them in Metro because they're more React-specific. And other integrations will need the same helpers. So I put them in the runtime too.

[gaearon]

Verified this works in RN.

[bvaughn]

We should eventually remove this check in React 😆

[bvaughn]

Changes seem good. Your recent prod-only errors are causing test-prod tests to fail though 😁