devtools

and we use it extensively for recording E2E tests for ourselves and for customers. (in fact, if you want to, all the E2E recordings for our own PRs are public - you could pop open any of the recordings from this PR I merged yesterday [0] and debug how the tests ran in CI.) But, our Chromium fork does not yet have the UI in place to let a user manually log in and hit "Record" themselves, the way the Firefox fork does. It actually automatically records each tab you open, saves the recordings locally, and then you use our CLI tool to upload them to your account. We're actually working on this "Record" button _right now_ and hope to have that available in the next few weeks. Meanwhile, our Chrome for Mac and Windows forks are in early alpha, and the runtime team is focusing on stability and performance. Our goal is to get the manual recording capabilities in place ASAP so we can switch over and make Chromium the default browser you'd download to make recordings as an individual developer. It's already the default for configuring E2E test setups to record replays, since the interactive UI piece isn't necessary there. Also, many of the new time-travel-powered features that we're building rely on capabilities exposed by our Chromium fork, which the Firefox fork doesn't have. That includes the improved React DevTools support I've built over the last year, which relies on our time-travel backend API to extract React component tree data, and then does post-processing to enable nifty things like sourcemapping original component names even if you recorded a production app. I did a talk just a couple weeks ago at React Advanced about how I built that feature [1]. Meanwhile, my teammate Brian Vaughn, who was formerly on the React core team and built most of the current React DevTools browser extension UI, has just rebuilt our React DevTools UI components and started to integrate time-travel capabilities. He just got a working example of highlighting which props/hooks/state changed for a selected component, and we've got some other neat features like jumping between each time a component rendered coming soon. All that relies on data extracted from Chromium-based recordings. [0] https://github.com/replayio/devtools/pull/9885#issuecomment-... [1] https://blog.isquaredsoftware.com/2023/10/presentations-reac...

but files like [3] show how I would write a real slice reducer with RTK+TS. [0] https://redux.js.org/usage/usage-with-typescript#avoid-actio... [1] https://github.com/reduxjs/cra-template-redux-typescript [2] https://github.com/replayio/devtools [3] https://github.com/replayio/devtools/blob/454804188d33900a26...

kend API to extract data from recordings and do other analysis, like generating code coverage reports and introspecting React's internals to determine whether a given component was mounting or re-rendering. Given that capability, we hope to add the ability to do "React component stack" debugging in the not-too-distant future, such as a button that would let you "Step Back to Parent Component". We're also working on adding Redux DevTools integration now (like, I filed an initial PR for this today! [2]), and hope to add integration with other frameworks down the road. [0] https://replay.io [1] https://github.com/RecordReplay/replay-protocol-examples [2] https://github.com/RecordReplay/devtools/pull/6601