Expose API for selectively overriding frontend host methods #168
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
In React Native DevTools, we currently use the frontend in hosted mode, which means
InspectorFrontendHostStubis our "live" implementation ofInspectorFrontendHostAPI.We're now exploring building a custom shell for RNDT (facebook/react-native#51687, facebook/react-native#51688), where it would be useful to override certain
InspectorFrontendHostAPImethods (with implementations that perform IPC calls to the host) while falling back toInspectorFrontendHostStubfor everything else (generally things that are well-served by ordinary web APIs). This isn't a workflow that the current frontend code allows.We have the following options:
InspectorFrontendHostAPIand get some stub methods copied over - but with no guarantee they'll work on the new object (as in the case of methods accessing private members onInspectorFrontendHostStub).InspectorFrontendHostAPI, at the cost of maintaining a fork ofInspectorFrontendHostStubthat could drift away from the upstream / plain hosted mode behaviour.InspectorFrontendHostAPIentirely - there is a separate IPC mechanism baked into the Chromium / CDT codebase (DevToolsAPI.sendMessageToEmbedderand friends) on top of whichdevtools_compatibility.jscan implementInspectorFrontendHostAPImethods. Again this involves maintaining a fork ofInspectorFrontendHostStub's functionality (albeit forced into a different shape), plus implementing an Chromium-internal API that is even less well-documented thanInspectorFrontendHostAPI.InspectorFrontendHostStubinstance right after it's created. (We mutate the instance as opposed to extending the class, so as to keep compatibility with the code path whereInspectorFrontendHostStubis not used).Test plan
Built the frontend locally and added the following test code in the shell's preload script:
With this, the shell launches, works as expected and foregrounds itself upon hitting a breakpoint.
Upstreaming plan
devtools-frontendrepo. I've reviewed the contribution guide.There might be a case for something like this in CDT, but I think we should get further into prototyping before we potentially involve the Chrome team. Note that if we wanted to delete this API, we could in principle fork the code for
InspectorFrontendHostStubat any time and inject a full version of it from the RNDT shell (option 2). So we're not tying ourselves super strongly to this custom API.