Update react-devtools-inline, react, and react-dom dependencies

[bvaughn]

Resolves #5344 and #4578; relates to replayio/gecko-dev#796

This react-devtools-inline update introduces a newer bridge protocol version than what is currently being embedded in the backend. That means older Replay sessions containing React data won't work with it.

I think the best short-term solution for this is for the devtools/client to check the protocol version embedded in the Replay, and load the react-devtools-inline version that supports it. This is a little hacky but it takes the pressure off of our ability to upgrade React DevTools without breaking backwards compat.

Checklist

• Update react-devtools-inline to latest (4.24.3).
• Update backend react-devtools-inline as well: Update React DevTools backend from 4.17.0 to 4.24.3  gecko-dev#796
• Update frontend to check protocol and dynamically load the React DevTools package that supports that version.
• Fix TypeScript types
• Add inline comments explaining what/why
• Maybe add tests (once we have shared Replay sessions with the new protocol version?)

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/recordreplay/devtools/5y335EN3q5zb8rvRGJDcWgJTawgN
✅ Preview: https://devtools-git-fork-bvaughn-react-devtools-inline-recordreplay.vercel.app

[jasonLaster]

@bvaughn makes sense.

Here are the docs on updating the react_devtools_backend. Updating the backend is sufficient for being able to land this PR and view the latest replays.

re backward compatibility: agreed. If the frontend knows the version we should be able to load it. There are some funny hoops to jump through because the react-devtools-inline is currently in our package.json, so i'm not too sure how we'd get multiple versions, but that feels more of an opsy challenge. Related, we don't currently have backward compat on the q2 roadmap because we assumed Component Stacks and some other features took precedence, but that's all flexible.

[hbenl]

Perhaps a solution to this could be to change our backend profile to include metadata about which backend version was used to record the "operations" message.

FYI: we're already fetching the ReactDevTools protocol version by sending the getBridgeProtocol message to the backend in the recording:
https://github.com/RecordReplay/devtools/blob/b36e7f0e2188a1a8788d92a4b8e1b01d93131b22/src/ui/components/SecondaryToolbox/ReactDevTools.tsx#L82-L83

[bvaughn]

@hbenl and I tested and verified that the changes in this PR and replayio/gecko-dev#796 are compatible. The remaining trouble is that– if we were to land these PRs, old Replays would "break" due to the React DevTools protocol version.

I'm going to see if I can't figure out a workaround to make the newer DevTools frontend support the older pre-recorded profiles.

[bvaughn]

I think the short term path forward here is to embed both versions of the react-devtools-inline package (4.17 which supports the older bridge protocol version and 4.24 which supports the newer one). Then we can look at the Replay and load the right frontend version based on the backend protocol that was captured.

This is kind of hacky but it unblocks us to update React DevTools.

I'm going to push this as-is so @hbenl can maybe verify that it works with the newer protocol version. (I can confirm that it works with an older protocol version.) I still need to clean things up (e.g. TypeScript types, inline comments, etc) but I'll do that a bit later. Need to pack and head to the airport shortly.

[hbenl]

This works for me with recordings made with both the old and the new backend. The only issue is that the ReactDevTools UI is not updated when jumping to a different point in time.

[bvaughn]

Okay. I think things should work more now like they used to, except for the async module-loading hop. Sorry for not catching the jumping-between-points issue during my smoke testing. I assumed that if DevTools loaded once it would work as usual from there on out– because of my mental model of how it runs in the browser under normal conditions.

[bvaughn]

As I start to understand the way Replay and React DevTools work together here, I realize that there's a small logic bug in the mount-only effect that might "break" things if we try to get the protocol version from a point too early in the Replay session. Going to make one more small change to account for this.