refactor: allow custom impl of backend realod-to-profile support check

[EdmondChuiHW]

Summary

In preparation to support reload-to-profile in Fusebox (#31021), we need a way to check capability of different backends, e.g. web vs React Native.

How did you test this change?

• Default, e.g. existing web impl = no-op
• Custom impl: is called

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 26, 2024 10:36am

[hoxyq]

Can it be backendSupportsReloadAndProfile or isReloadAndProfileSupportedByBackend?

The final version is up to you, I just want it to explicitly mention that this is about backend.

[hoxyq]

I think we should move it somewhere. Can this actually be an argument on initBackend?

Notice that you don't have any changes related to the browser extension, this is because it has its own logic for backend initialization:

react/packages/react-devtools-extensions/src/contentScripts/backendManager.js

Lines 99 to 161 in fc4a33e

	function activateBackend(version: string, hook: DevToolsHook) {
	const backend = hook.backends.get(version);
	if (!backend) {
	throw new Error(`Could not find backend for version "${version}"`);
	}
	const {Agent, Bridge, initBackend, setupNativeStyleEditor} = backend;
	const bridge = new Bridge({
	listen(fn) {
	const listener = (event: $FlowFixMe) => {
	if (
	event.source !== window ||
	!event.data ||
	event.data.source !== 'react-devtools-content-script' ||
	!event.data.payload
	) {
	return;
	}
	fn(event.data.payload);
	};
	window.addEventListener('message', listener);
	return () => {
	window.removeEventListener('message', listener);
	};
	},
	send(event: string, payload: any, transferable?: Array<any>) {
	window.postMessage(
	{
	source: 'react-devtools-bridge',
	payload: {event, payload},
	},
	'*',
	transferable,
	);
	},
	});
	const agent = new Agent(bridge);
	agent.addListener('shutdown', () => {
	// If we received 'shutdown' from `agent`, we assume the `bridge` is already shutting down,
	// and that caused the 'shutdown' event on the `agent`, so we don't need to call `bridge.shutdown()` here.
	hook.emit('shutdown');
	});
	initBackend(hook, agent, window);
	// Setup React Native style editor if a renderer like react-native-web has injected it.
	if (typeof setupNativeStyleEditor === 'function' && hook.resolveRNStyle) {
	setupNativeStyleEditor(
	bridge,
	agent,
	hook.resolveRNStyle,
	hook.nativeStyleEditorValidAttributes,
	);
	}
	// Let the frontend know that the backend has attached listeners and is ready for messages.
	// This covers the case of syncing saved values after reloading/navigating while DevTools remain open.
	bridge.send('extensionBackendInitialized');
	// this backend is activated
	requiredBackends.delete(version);
	}

Then, inside initBackend, we could do something like:

if (isReloadAndProfileSupported()) {
  agent.onReloadAndProfileSupportedByHost();
}

and inside Agent this method would just send this event:

this._bridge.send('isReloadAndProfileSupported', true);

and the only remaining thing is hardcoding true for initBackend call in the extension code, which I've referenced above

[hoxyq]

This will allow us to reuse as much as possible, and reduce the fragmentation: instead of having custom logic, like here in react-devtools-core/src/backend.js, we would pass an argument to initBackend, which is from react-devtools-shared

[EdmondChuiHW]

Great idea! Much cleaner to have this logic back into Agent/initBackend. Updated

[hoxyq]

This won't do anything, because you don't store it on the Hook object, and you don't need to.

Can you add boolean optional parameter to initBackend here?

react/packages/react-devtools-shared/src/backend/index.js

Lines 16 to 20 in a15bbe1

	export function initBackend(
	hook: DevToolsHook,
	agent: Agent,
	global: Object,
	): () => void {

Then, anywhere where you are calling initBackend: browser extension content script, react-devtools-core, react-devtools-inline, you will provide this argument.

For browser extension it will be true by default, for react-devtools-inline it will be false (we don't support it), for react-devtools-core this will be the return of the function isReloadAndProfileSupported, which is passed from the Host (React Native in our case)

[hoxyq]

Can this be boolean with a default value false? And then wrappers around it are going to pass just a boolean value, and react-devtools-core is going to pass getIsReloadAndProfileSupported().

With a current implementation, the extension is going to use defaultGetIsReloadAndProfileSupported, but actually it should just receive a static true value.

[EdmondChuiHW]

Wouldn't the extension still need to check the local/session storage capabilities, e.g. incognito mode?

Edit: I'm inclined to keep this PR focused on just the refactoring, i.e. keeping existing things working the way it has been, even if it's suboptimal/obsolete. We can follow up and remove the checks in a separate PR as needed