Building Better React Debugging with Replay Analysis

All right, good afternoon, thank you very much. My name is Mark Eriksson, and today I am very excited to talk to you about building better react dev tools with replay time travel analysis, the title changes, whatever. Thank you for being here. I'll be honest, this is probably not going to be the most actionable talk. There aren't a lot of things. It's like I can go home and like immediately change my code.

We will definitely be diving deep today. I will have the slides up on my blog later today, blog.i2software.com, and very happy to answer questions about this later. A couple quick things about myself. I am a senior frontend engineer at Replay, where we are building a time traveling debugger for JavaScript, and we will talk about that. I will answer questions anywhere there is a text box on the internet. I collect all kinds of interesting links. I write ridiculously long blog posts, and I am a Redux maintainer, but most people know me as the guy with the Simpsons avatar.

Out of curiosity, how many people... we will get to the React stuff in a second. One quick note. Redux Toolkit 2.0 is in beta. We would really appreciate people trying that out and giving us feedback. Let us know how the new feature works. Give us feedback if we should try to change some of the API designs before it goes final. Please, please try that out and let us know how it works. ETA soon. How many of you have the React DevTools extension installed in your browser? Okay, good. That's most of the hands. Very happy to see that. The React DevTools are a wonderful aid for understanding what is going on in your React app. It's one of the great advantages they have over earlier frameworks like Backbone. What are they? They let us inspect the component tree in the page. They show us the parent-child relationships, the order of the components, and if you select a component, then it will show you the current props, the hooks, the state, even something called the owner tree, which is the chain of components that rendered it. It is an extremely valuable tool for understanding your React app.

The React dev tools also have a profiler panel. You can hit the record button, use the app for a minute, and it will show you a list or a count of all the times that the application rendered, and for each render, it will show you which components in the tree rendered, and how long each of them took. The flame graph gives you a relative sense of this component took twice as long as that one. Very valuable for understanding the overall performance of your app.

But how does this even work? Magic. Okay. Not actually magic, but a lot of very careful engineering. So we know function components and class components. But in a lot of ways, those are just kind of like little facades over the actual data. Internally, React has a data structure called a fiber. And each fiber represents one component instance in the tree. And so React stores the type of the component, literally the function or the class. It stores the current props. It has a linked list that points to parents and siblings and children, and a whole lot of other internal metadata. And so, this truly is the real tree of the components. Every time React finishes a render, it has this tree of fibers that represents the component instances.

So, when you install the browser extension, React, that gets loaded into every page and it injects some JavaScript. And this creates a global variable, double underscore React DevTools global hook, double underscore. And this is how React in the page is going to talk to the browser extension. So, this global hook object, which by the way, has nothing to do with hooks, like use whatever, it's just a naming collision. It stores references to every different copy of React that's in the page. It has some event emitter capabilities and it has some callbacks that React will run every time it has rendered. So, when you load React in the page, one of the first things it does, is it looks to see, does this global hook object exist? And if so, it knows that the browser extension is there and it will try to send the information later.

So, every time React finishes rendering at the end of the commit phase, it will then talk to the global hook and run this on commit fiber root method. And it passes over the top level fiber representing the root component for the whole tree. And now, at that point, the browser extension has some code that runs inside the page, and it can look at the tree of components and see what is there and what did the tree look like before that. So, how does it know what the component tree looks like? I mean, it's obvious. It's right there. We can all read this, right? So, the fiber tree actually has pointers to the previous version of the tree from the last commit as well. And so, during the commit phase, when it runs this callback, the extension code in the page can walk over the tree and diff it to compare here was the tree last time versus here is the this time.

And it's specifically trying to understand what parts of the tree structure changed. What components were added, or removed, or reordered. And it's going to try to describe this in a very efficient way. Because there could be hundreds of components that changed, and it needs to send that information from the main browser process to the extension UI process. And that could be a lot of data to serialize.

So the React dev tools has an operations format that is all strictly numerical codes. And so, if we break down this array, a typical operations array contains these variables. There's the ID of this copy of React in the page. There's the ID of the React root. Because you could have said render some React render some React over there. And then we have to have all the strings for the component names. So, it says there's five unique component names that are new in this commit. And then it has the UTF numeric codes for each character. So, like to do list or to do item. Then we're going to describe each change to the tree as a unique operation. So, we're going to add a to do list item component. It is a function component. Its parent has this ID, the owner has an ID, and then we have to have the indexes into the string table so that it knows what name is associated with that component. And so, this is a very efficient way to transmit all of that information. So, a typical operations array could have hundreds potentially of separate operations and be thousands of numbers long. But this just has the information on the structure of the tree. It doesn't have information on the details.

So, when you select a component, the extension UI sends an async request into the page and the extension code in the page looks at the fiber, describes it, and sends back the data to the UI to say here's your props and your hooks and your state. So, that's the basics of how the React DevTools works. Let's shift into sales mode. So, my day job is working at Replay, where we're building a time-traveling debugger. And the idea is, you record yourself using your own application for a couple of minutes with our modified versions of Chrome or Firefox. And once you've done that, you can debug the recording with time-travel super powers. You can jump to any line of code in the recording, you can see how many times did it run, you can add print statements without changing the code, and it logs out what it would have logged every time that line of code got hit, you can see console messages and DOM elements, and you can see the React component tree at every point in time. This records everything in the browser.

It's not framework specific. You can use it with Vue, Angular, jQuery, whatever. But we use React. We are very involved in the React community, and our goal is to make Replay the best debugger for React, period.

Now, I know for a fact that some of the actual React core team members have used Replay, and a number of the developers at Next.js have used Replay. In fact, Tim Newkins, one of the leads on Next, tweeted out earlier this year that when they released Next 13.4 with the app router, they had some very tricky bugs, and the only way they were able to fix them was by using Replay to make recordings of Next, track down some timing-related problems, and fix them.

So, our first recording browser was Firefox. Our founders started as Firefox DevTools engineers. And when I joined Replay a year and a half ago, we had React DevTools support. But the way we implemented it was not very maintainable. We actually copy-pasted the entire React DevTools extension bundle, pasted it into the Firefox source code, and loaded it into every page, so that every time you made a recording, the extension was there and React would save the data. And then we captured the data and we saved it in this little object format called an annotation to persist it to our server. And that way we had the time stamps of every time React updated, and we had a copy of all these operations arrays. And it worked, but there were some limitations. It did slow down the recording process a little bit. You had to have the same versions of the dev tools code in Firefox and in our UI to read the data, and it's hard to update the bundles.

So, Replay has an API. Like, all the magic happens in the cloud. And it basically gives you time travel superpowers as an API. So, it has all these methods to pause a browser process, ask for the stack frames and the variables and the scopes, and all these other things. This is publicly documented. Anyone could sit down and write scripts that use this right now. And our entire front end is built on top of this protocol. So, we've started working on trying to make Chrome our primary recording browser. It works great for Linux right now. Windows are still in early alpha. There's still some features we need to fill out to get parity. But late last year, we were talking about it. It's like, we don't have React dev tool support in our Chrome fork yet. We don't like the idea of copy pasting the bundle.

Surely, there has to be a better way that we can do this. So, the idea was, what if we used our time travel API to pull all the React information out of a recording of the app and save that for use in our debugger client. So, there is no extension installed in Chrome. We're going to have to figure out a way to post process the recording and extract this data.

We don't know when React actually rendered, and how do we get those operations values anyway? So, our idea was in our backend server every time someone opens up a recording to debug it, we're going to kick off an extra little background process that uses our APIs to extract the data. And then, in order to make that possible, we're going to have to put code into our fork of Chrome to capture timestamps so that we even know what points in time React committed during the recording.

So, most of our modifications to Chrome are in one 6,000 line file that's a mixture of C++ and JavaScript inside C++ strings, which is horrible. But, we went in, mostly me, and I created, like, a fake little version of the React DevTools hook object. And that gets loaded into every page, so that React, during the recording, thinks it's talking to the extension. But, during the recording process, it's just saving timestamps, React rendered, React rendered, React rendered. That way, we know, later on, what points in time actually matter. There's a lot of extra tricky pieces of bookkeeping. I have to do some saving of React fiber variables and render variables to save for later, but it's maybe 100 lines of code. It's not too bad.

So, on the back end, we set up some scaffolding so that every time a user opens up a recording for the very first time and we don't have any data saved, we kick off a background process that has access to our protocol and can now start to call these analysis APIs to extract data. Now, you could write any standalone Node script that uses our protocol. We actually have some examples in a repo that we've put together. But conceptually, a routine is just like a background process that can call protocol methods. So, the basic idea is we first get all these annotations with the timestamps. Then we're going to have to actually send a copy of the React DevTools JavaScript code into this paused browser in the recording. And then for every commit, we're going to ask that bundle, give me all the operations for that commit. We have to do a little more reformatting on the data. And then finally, we can save this information so it can be used by our client UI.

So, how do you run code via time travel? And it's everybody's favorite tool, eval. Now of course, we've been told for years using eval is bad, and evil, and dangerous, and a security risk. And it's probably right. But in this case, it's the hammer that solves everything. So, you can send, like an eval is just, here's a string of code, hey JavaScript interpreter, please run this as if it was real code. We can send a string of code over the network and run it inside a paused browser in the recording in the cloud and it actually works. So, in this example, I'm just evaluating like a tiny little string and it's a few lines.

And I can return results from that eval. And then our protocol lets us inspect the content. Was it a primitive? Was it an object? An array? What are the fields in that object? And we can get back all the details. The evaluation code can mutate the paused environment. If I change a variable or add something to a global, it sticks around for later. And this is important. Because if you can eval like a five line piece of JavaScript, you can eval a 150K minified JavaScript bundle.

And now, writing codes in strings is very not maintainable. And this is actually a problem we had when I joined Replay. What I figured out, one of the quirks of the JavaScript language is if you call any function .toString, you get a string of the function declaration and its source code. Which means you can send that string over the network. And so what we've done is we've written these functions in TypeScript. At compile time, the types get stripped away and it's just a plain JavaScript function. And then you function.toString and then you evaluate it and it just magically works. It's great. You do have to be careful, you can't close over any other variables. The function has to be self-contained.

Now let's get really complicated. So you can pause the recording at many points in time and our protocol gives back numerical IDs for any object. But it doesn't know that a variable is the same reference at two different points in time, it might be a different object ID each time. So we actually had to modify Chrome to consistently give us persistent object IDs across many points in time. Except the only thing we have done is React Fiber objects specifically for this. We are eventually going to add persistent IDs on the back end for any object at any time. We don't have that yet. Another thing is that the React DevTools JavaScript code has a lot of important functions for calculating the diffs in the trees and generating IDs, those aren't exposed publicly. So what did we do? We forked the React DevTools. I've got a branch and a draft PR. I've messed with some of the internals of the React DevTools and deleted a bunch of code that we didn't need for our use case to try to shrink down that $150K bundle. And on top of that, all this is happening during the background post processing. But what happens when you're debugging the recording from our UI? We're going to have to have React in the page in the PaaS browser so that the UI can say, like, what are the props for this component.

But it's the recording. It doesn't exist yet. So, we actually also inject that same bundle from our client side into the PaaS recording so we can ask for the props. I told you this was complicated. So, that has given us the equivalent of the React DevTools extension. We have the operations and as you're debugging the recording at different points in time, we can show you what the component tree looked like.

What if we can do better? I'm almost out of time, ironically, so going fast. In production apps, function names are minified because they have all been shrunk down. Via the power of time travel, we can say where was this component defined, what was the original file name, what was the actual original name of the component, and we can rewrite all of the component names to their original versions, even if you made a recording of a production app.

So, what does this roughly look like? This is a very slimmed down version of the top of our routine. So, we fetch those annotation objects. Now we know what points in time we care about. We evaluate the code at each point to inject the React dev tools and fetch the operations data. We reprocess that to figure out the original component names, rewrite the operations data with the new component names, and save those for later. And when you go to debug a recording, we now have the operations data, and we can show you the component tree as it existed at any point during the recording. The code for this is semi-kind of open source. It lives in our proprietary back-end repo, but there's nothing special about it. It's just calls to our public API. So I actually have copy-pasted all 2,500 lines of the back-end post-processing routine stuff. It's in that repo. It's available. You can take a look at it. You can see all the dirty, stupid, ugly hacks that I've had to write to make this work.

We also have a few other features, and I'm about out of time, so going quickly. I've built something called jump-to-code, where we know that you've clicked or pressed a key in the application. We can figure out what React on click or on key press prop ran in response and jump you to that line of code at that time so that you can start debugging. I know if I press this button, something exploded. It gets you closer to where that probably happened. We've also built the Redux DevTools equivalent, which extracts the action types, shows you the list of the actions, the state, and the diff, and we've got a number of other features in progress. One of my teammates is Brian Vaughn, who built most of the React DevTools extension UI, and he now works for Replay.

We're actually rebuilding our React DevTools integration. It's faster and more efficient. We have a proof-of-concept feature that shows you a list of every time your app called setState at all, and you can jump to that code. I did a proof-of-concept that breaks down performance timings for Redux dispatches, and we have a lot of other features we want to build in the future.

React component stacks, to see what the tree was at a point in time in the code, commits timeline, and previous next change props. Last item, really fast, React doesn't ship with Source Maps. If you're debugging, you want Source Maps, so you see the original code. Five months ago, I filed a PR to modify React's build pipeline to generate Source Maps. Sadly, this has not merged yet. So I backported the changes to the earlier versions of React and made the Source Maps that would have existed for 18.2, 18.1, and 17. We now have a plug-in package for your build tools that will rewrite those as you build your app.

Okay, that's a lot of information. Thank you for sticking with me. I have links to these. I will have these slides up on my blog at blog.isquaredsoftware.com or please come by and ask questions. Hopefully this has been useful and insightful. Please check out replay. It will make your debugging a lot simpler and easier to work with. And hopefully this makes your React apps easier to debug. All right, now there are lots of questions that have come in. This was a hot topic. Really, really exciting. I also love especially whenever I get to learn about a new tool that I want to use or want to try and incorporate into my sort of developer workflows. I'm going to be trying out replay. I'm now definitely going to be… You have not the not so subtle corporate plug. Hey… gotta pay the bills, gotta pay the bills. All right, so the first question… Now, it's funny because you said replay was built and it was built on Firefox's browser. The first one is… and I'm curious as to whether this is possible. Replay for React Native? Not any time soon. So, we have a set of very, very smart browser C++ engineers.

The forks are public. You can see the code if you want to, but it's like an extra five or six thousand lines of C++ code and JavaScript changes per browser to enable capturing all this information. So, Firefox is stable for all platforms. Chrome for Linux records okay. Still need some UI work. Chrome for Mac and Windows is an early alpha. We have a Node alpha as well. I've used it to record and debug some jest tests over time. Right now the goal is to get the Chrome forks up to parity. Switch over to make that the primary browser. Then focus on Node. We could maybe do React Native someday, but this is like multiple years down. It's way down under the list of priorities, but that makes sense, especially when you think about what users are using.

Some people are excited to get their hands on and try Replay. They ask if Replay is free or is there a pricing model? Replay is free for individuals and open source developers. We would love for more open source projects to adopt Replay as part of their issue flow. Everyone's like, can you please attach a code sandbox or a GitHub repo that demonstrates the issue? Having a replay of the issue where you can just open it up and immediately debug, no set up processes or anything. Speaking with my open source maintainer hat on, it makes it a lot easier. There is a small per-pricing model for companies with developers, but we're very flexible on that. I love that. The reason why I had to trigger that applause is I always love it when companies really support the open source community and replay.

I'm guessing because it is a browser, it works offline and on-prem as well? Yeah, our recording browsers are truly Firefox and Chrome just with extra pieces built in. The recording stuff only kicks in once you actually hit the button. We have some hypothetical long-term goals that someday it could be in permanent record mode, kind of like a video game. You see the thing that happened that was interesting, you hit like the save highlight button? That's also a few years down the road, but that's where we'd like to get to. No, that's interesting, especially considering the fact that most of us, we have like the browser we use, or the way we use our browser for just general day-to-day use, and then the way we use our browser for like working on our apps and it will be interesting to see how Replay could maybe become just a developer browser, right? That is kind of our no-kidding goal. Good to know and then the next one, I think I actually skipped it, by the next one, sorry the questions are moving around, is about fragility of the system. So considering like you've got like quite a lot of, for lack of a better term, hacks like going along. Yeah. Like what do you just see from long-term stability of Replay? So there's definitely some parts where the features that I've built are kind of dependent on certain React internals.

The React render panel thing that I talked about specifically depends on the fact that every time you call setState in any form, useReducer, useState, anything else, it always goes through one central function inside React called scheduleUpdateOnFiber. And with the way our protocol works, I can find a function by that name by asking our protocol about it. But that only works with development builds of React, especially because the production builds don't have source maps yet. But I figured out that production builds of React, the way it gets minified, there's always a numeric error code of parentheses 185 in that one function. So if I search the React source code for parentheses 185, I find the right... You see why I wanted the source map. This sounds painful.

It is. So it's not sustainable. It's not the way I'd like to do things, but part of it is like, can I make it work right now? And we were trying to have more conversations with the React team. In fact, there's a member right down there. We want to have more conversations about like, you know, if you could expose a couple extra callbacks or something, then we could build extra useful features in a stable way. Yeah. Hopefully it works out because I think having not just React be an ecosystem, but has an ecosystem of tooling and better tooling around it, it will make all of our lives way more easier.

All right. We only have one more time for one more question. The questions are moving around. So thank you for upvoting on the questions that you really like. Someone says they're super confused about the fact that they need a BE, I think it means browser engine in this scenario, running in a cloud. Can't it just run in the browser plugin? So what Replay records is the browser talking to the operating system. Every time the browser opens up a network socket, receives a packet, makes a math random call, all the calls to the operating system are what gets recorded. As an example, like if you make a tic-tac-toe game with a random number generator, and you seed the random number generator, so it always produces the same numbers every time. You can predict how the tic-tac-toe game will happen. And so in the same way, because we record all the inputs to the browser as you were using it, later on, we can start up the browser in the cloud, feed it those inputs, and then run it ahead and kind of like pause it at many points in time. And when you say, I want to jump to 17.5 seconds, it finds a paused copy of the browser, forks the process on Linux, and runs it ahead another like half a second. It sounds like wizardry.

It is. It's a lot of very, very smart engineering. I am not smart enough to have done that. I just get to use it.

That is amazing. Look, there are so many more questions, and I'm sure that people, we could just spend all day asking about this. But I know you will be in the speaker discussion room. Is it right after this? I think I'm in the discussion room. After the speaker room. The speaker room right after this. And then I have to run to a panel on the main stage. And yeah. You're in high demand. High demand. But let's give it up for him one more time.