Analysis based react devtools backend

[bhackett1024]

Currently we have a version of the react devtools backend which we load into every recording made using the replay browser. Any react on the page will detect this backend and call into it, and it will add annotations to the recording which clients inspecting the recording can read and use to reconstruct the react state at any point in the recording.

This approach works but it doesn't scale well in a couple of ways:

1. The backend version is fixed for the lifetime of a recording, and a matching version of the frontend needs to be used in order to inspect its react state. This makes it hard to upgrade the frontend / backend without breaking support for older recordings.
2. The backend is a substantial amount of code, and if we wanted to do something similar for other framework devtools we would potentially need to load quite a bit of code into every recording, on the off chance the backend would be needed.

It would be better if we didn't load a specific version of the backend into each recording. There is already an interface between the devtools backend and the react code running on the page which works across different versions of react. If the client loaded both the frontend and the backend for the react devtools (where the versions always match), and inspected the recording to find all the sites where react would have called into the backend, it should be able to extract the necessary information from those sites to populate its copy of the backend with the react state changes made throughout the recording.

We should be able to find the sites where react would have called into the backend by loading a shim version of the backend into each recording which is much smaller and just annotates the recording with all the calls that react is making.

The main unknowns for me is understanding what information the backend needs from these sites in order to work, and how difficult it would be to get this information from the recording instead of values that are being passed in. I suspect the protocol is not expressive enough yet to deal with this use case. Mainly, each site will be a different pause point, and we don't have a way to compare objects between different pauses. So if the backend keeps track of metadata for a react object at one site, it won't be able to determine that object's metadata when it is accessed at a different site. We've wanted to address this limitation for a while though, and being able to improve the architecture of our react devtools support and address the above difficulties would be a good impetus for this.

[bvaughn]

I wrote a related issue on the React side about DevTools protocol versions. Seems relevant so I'll link it here:
facebook/react#24219

We should be able to find the sites where react would have called into the backend by loading a shim version of the backend into each recording which is much smaller and just annotates the recording with all the calls that react is making.

This sounds promising, although I don't have a very thorough understanding of how the backend stuff works at the moment.

[bhackett1024]

Hmm, to be a little more concrete (and improve my understanding) I went through how things currently work and how they should be able to work with the react devtools backend living in the client. From what I can tell this should be able to work, but we definitely need support for persistent object IDs (https://github.com/RecordReplay/backend/issues/5144) first.

Currently in every recording process we load a modified version of a specific version of the react devtools installHook function, and a modified version of the react devtools backend into the main window [1]:

https://github.com/RecordReplay/gecko-dev/blob/e5f3493bfcfffe07ecf9905e2ac42e61f655121d/devtools/server/actors/replay/react-devtools/contentScript.js#L28

Any react on the page will detect the __REACT_DEVTOOLS_GLOBAL_HOOK__ object which installHook adds to the window, and call its methods in the usual way. Those methods call into the devtools backend, e.g. the hook's onCommitFiberRoot calls the backend's handleCommitFiberRoot here [2]:

https://github.com/RecordReplay/gecko-dev/blob/e5f3493bfcfffe07ecf9905e2ac42e61f655121d/devtools/server/actors/replay/react-devtools/hook.js#L281

The backend does its usual thing, but instead of posting a "react-devtools-bridge" message to the frontend it has been modified from the stock backend to call a __RECORD_REPLAY_REACT_DEVTOOLS_SEND_BRIDGE__ method installed on the window, which adds a "react-devtools-bridge" annotation to the recording [3]:

https://github.com/RecordReplay/gecko-dev/blob/e5f3493bfcfffe07ecf9905e2ac42e61f655121d/devtools/server/actors/replay/react-devtools/contentScript.js#L22

The devtools frontend read these annotations from the recording and feed them to the react devtools frontend, as if they had been received as messages from the backend. (Incidentally this doesn't check for the "react-devtools-bridge" kind, which looks like a bug, filed https://github.com/RecordReplay/devtools/issues/6132). [4]

https://github.com/RecordReplay/devtools/blob/10312a15c8b802dd07124a3c4a94963db0587737/src/ui/actions/reactDevTools.ts#L19

What would be good to do instead is to avoid loading the react devtools backend into the recording process, and change the methods in the devtools global hook so that they add annotations to the recording instead of trying to call into the backend. For example, in [2] the hook's onCommitFiberRoot wouldn't call handleCommitFiberRoot, but would add a "react-devtools-onCommitFiberRoot" annotation or something to the recording.

The devtools frontend can read these annotations as in [4] and get any information it wants about the current state of the program when that annotation was added. Each annotation includes an ExecutionPoint value which is used to create Pause objects in the protocol and check the contents of the stack and all variables, objects, etc. reachable from any of the stack frames. This could find the rendererID, root, and priorityLevel values which were passed to onCommitFiberRoot, and pass them to handleCommitFiberRoot in a version of the react devtools backend loaded as part of the devtools frontend. These values passed in would be ValueFront objects, though it would be slicker to create proxies so that they can be interacted with like normal objects (as long as any properties the backend will inspect have been loaded ahead of time, which must be done async).

The limitation we'll run into here though is that currently ValueFronts from different pauses are not comparable. So if onCommitFiberRoot is called repeatedly with the same root, by inspecting the annotations we can see all those calls but we can't tell whether the call is being made with the same root multiple times or different roots every time.

It looks like this will break the backend pretty quickly. handleCommitFiberRoot (and many other places in the backend) call getOrGenerateFiberID, which maintains a fiberToIDMap map between objects referenced by the root and IDs generated by the backend. This will not work at all when we can't tell the objects from different pauses apart.

https://github.com/RecordReplay/gecko-dev/blob/e5f3493bfcfffe07ecf9905e2ac42e61f655121d/devtools/server/actors/replay/react-devtools/react_devtools_backend.js#L7314

We need persistent object IDs (https://github.com/RecordReplay/backend/issues/5144) in order to support functionality like fiberToIDMap. When we have this, we'll be able to determine whether object IDs referenced by different pauses are the same or different underlying object. Extending the proxy idea above, we could create object proxies that are 1:1 with objects in the original recording, and by reading the annotations from the recording and creating the appropriate proxies we should be able to call the react devtools backend with those proxies and it would more or less just work and generate the "react-devtools-bridge" messages which need to be passed to the react devtools frontend.

At that point one potential remaining stumbling block would be if the react devtools backend methods like handleCommitFiberRoot mutate any state in the page or the page's objects which could affect the page's behavior or the behavior of later backend methods --- changes made to the page state at one pause will not be reflected in pauses at later points in the recording. I don't think this would be the case, e.g. the backend is using fiberToIDMap instead of, say, setting a __fiberID property on the fiber object. If it is though, we would need to find other techniques which avoid the state mutation.

[bvaughn]

Incidentally this doesn't check for the "react-devtools-bridge" kind, which looks like a bug

Agreed. This would potentially break things.

What would be good to do instead...change the methods in the devtools global hook so that they add annotations to the recording instead of trying to call into the backend...The devtools frontend can read these annotations...and pass them to handleCommitFiberRoot in a version of the react devtools backend loaded as part of the devtools frontend.

I was a little confused by how this was presented, but if I understand correctly– you're essentially proposing:

1. The Replay recorder stashes the Fiber tree at the time of the React commit.
2. The Replay player embeds both the React DevTools frontend (like it already does) and the backend (which would be a change).
3. Somehow the player feeds the React DevTools backend the stashed Fiber information like it would in a normal browser session.

That approach makes sense (though I don't fully understand how the 3rd step would work). I see how the lack of persistent object IDs is a blocker for this.

At that point one potential remaining stumbling block would be if the react devtools backend methods like handleCommitFiberRoot mutate any state in the page or the page's objects which could affect the page's behavior or the behavior of later backend methods...

React DevTools backend does mutate properties of the Fiber in some cases (like when a user modifies an inspected component's props and state) but this can be disabled by passing a readOnly prop to the frontend's root <DevTools> component.

[bhackett1024]

That approach makes sense (though I don't fully understand how the 3rd step would work). I see how the lack of persistent object IDs is a blocker for this.

Yeah, the stashing idea is more like marking the places in the recording where the react commits happen. The client can then go and visit each of those points (like it was in a time machine) and access any of the program's state at them, feeding the backend that state as if it was happening right now.

React DevTools backend does mutate properties of the Fiber in some cases (like when a user modifies an inspected component's props and state) but this can be disabled by passing a readOnly prop to the frontend's root <DevTools> component.

Ah yeah, we'll want to make this read only for now, similar to what we do for the elements panel. Eventually we want to explore allowing the client to make changes to the state and see how the recorded application would have (well, might have) behaved afterwards, but that is still some ways off.

[jasonLaster]

Moving this to a discussion so we can continue discussing this approach. When we're ready to pick it up we can either move it back to an issue or make a new more actionable issue.