Building Better React Debugging with Replay Analysis

Rate this content

React's component model and one-way data flow give us a great mental model for building our apps, but debugging React apps can still be confusing. React's internals are a black box, and it's often hard to understand why components rendered or what caused errors.

The Replay time-travel debugger makes it easier to debug React apps by letting you inspect what's happening at any point in time. But what if we could go beyond the usual debugger features, and build new debugging features that tell us more about what React is doing? Let's see how Replay's API makes that possible.

31 min
20 Oct, 2023

Video Summary and Transcription

Today's Talk focused on building better React dev tools with replay time travel analysis. The React DevTools provide valuable insights into React apps, using a fiber data structure to represent component instances. Replay is a time-traveling debugger for React, with plans to make Chrome their primary recording browser. They extract React information from recordings using their time travel API and have built a UI for debugging and inspecting the content. The long-term goal is to have Replay work offline and in permanent record mode.

Available in Español

1. Introduction to Building Better React Dev Tools

Short description:

Today, I will talk about building better react dev tools with replay time travel analysis. Redux Toolkit 2.0 is in beta, and we appreciate your feedback. The React DevTools are a valuable tool for understanding your React app.

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,, 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.

2. Understanding React Dev Tools

Short description:

The React dev tools have a profiler panel that shows the number of renders, the components rendered, and their rendering time. It uses a data structure called a fiber to represent component instances. React communicates with the browser extension through a global hook object, allowing it to send information about renders. The fiber tree has pointers to the previous version, enabling the extension to compare the current and previous trees during the commit phase.

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.

3. Understanding React Dev Tools and Replay

Short description:

The React dev tools use an operations format with numerical codes to efficiently transmit information about changes in the component tree structure. When selecting a component, the extension UI sends a request to the page, and the extension code describes the fiber and sends back data on props, hooks, and state. In addition to React DevTools, Replay is building a time-traveling debugger that allows recording and debugging of applications with time-travel capabilities.

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.

4. Replay: The Best Debugger for React

Short description:

Replay is a debugger for React, used by the React core team and developers at Next.js. It started with support for Firefox, but the implementation was not maintainable. Now, Replay has an API that provides time travel superpowers as an API. They are working on making Chrome their primary recording 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.

5. Extracting React Information from Recording

Short description:

We used our time travel API to extract React information from a recording of the app. We kick off a background process to extract data from the recording and capture timestamps. We save React render timestamps and use a fake React DevTools hook object. We set up scaffolding to extract data using our protocol and save it for the client UI. We run code via eval, sending a string of code to the paused browser in the recording.

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.

6. Debugging Recording and React in UI

Short description:

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. This is important because if you can eval like a five line piece of JavaScript, you can eval a 150K minified JavaScript bundle. Writing codes in strings is not maintainable. We've written these functions in TypeScript, stripped away the types at compile time, and evaluated them as plain JavaScript functions. You have to be careful not to close over any other variables. Let's get really complicated. Our protocol gives numerical IDs for any object, but it doesn't know if a variable is the same reference at different points in time. We modified Chrome to give us persistent object IDs. We forked the React DevTools, modified its internals, and deleted unnecessary code to shrink the bundle. React needs to be in the page for debugging the recording from our UI.

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.

7. Debugging Recording and React

Short description:

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. 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. We've also built 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. 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.

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.


Rebuilding React DevTools and Q&A

Short description:

We're rebuilding React DevTools for better performance. We have a proof-of-concept feature to track setState calls and performance timings for Redux dispatches. We also plan to add React component stacks, commits timeline, and support for Source Maps. Check out our blog for more information and feel free to ask questions. Try replay for simpler debugging of React apps. However, Replay for React Native is not planned at the moment.

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 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.

Replay: Pricing, Goals, and System Stability

Short description:

The forks are public, and Firefox is stable for all platforms. Chrome for Linux is recording okay, but still needs some UI work. Chrome for Mac and Windows is in an early alpha stage. Replay is free for individuals and open source developers, with a small pricing model for companies. The long-term goal is to have Replay work offline and in permanent record mode. However, there are some dependencies on certain React internals.

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.

React Render Panel and Time Travel Debugging

Short description:

The React render panel depends on the central function scheduleUpdateOnFiber. Development builds of React work with our protocol, but production builds lack source maps. We want to have conversations with the React team to improve tooling. Replay records browser interactions with the operating system, allowing for time travel debugging. It's a complex engineering feat.

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.

Speaker Discussion and Panel

Short description:

There are many more questions, and the speaker will be in the discussion room and then on a panel on the main stage. Let's give it up for him one more time.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
JSNation 2023JSNation 2023
29 min
Modern Web Debugging
Few developers enjoy debugging, and debugging can be complex for modern web apps because of the multiple frameworks, languages, and libraries used. But, developer tools have come a long way in making the process easier. In this talk, Jecelyn will dig into the modern state of debugging, improvements in DevTools, and how you can use them to reliably debug your apps.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Top Content
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.