Expo-vember's epic finale! Jamon Holmgren talks with Cedric van Putten (Expo) and Alex Hunt (Meta) about the new React Native DevTools and how they’re revolutionizing debugging for developers.
Expo-vember's epic finale! React Native’s debugging tools are getting a major upgrade! Host Jamon Holmgren talks with Cedric van Putten (Expo) and Alex Hunt (Meta) about the new React Native DevTools. They discuss why the teams joined forces to build a more reliable debugging experience, the power of Chrome DevTools Protocol, and what’s coming next for React Native debugging. Plus, learn why debuggers beat console.log and how the new tools make debugging more accessible for developers on all platforms.
Show Notes
Connect With Us!
This episode is brought to you by Infinite Red!
Infinite Red is an expert React Native consultancy located in the USA. With nearly a decade of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter, core React Native contributors, creators of Ignite and Reactotron, and much, much more), Infinite Red is the best choice for helping you build and deploy your next React Native app.
Todd Werth (00:10):
Welcome back to React Native Radio podcast, brought to you by chat GPT Pro. It won't stop thinking until you pay your $200. Episode three 16 debugging the debugger.
Jamon Holmgren (00:36):
I'm Jamon. This is React native of radio and I have two amazing guys here. Start with you, Cedric Van Putin. Fun fact. I call Cedric my Dutch son of course. And because my son's name is also Cedric and in fact, I don't know if I've told you this, Cedric, but I actually tried to get the domain name cedric.dev and I was really bummed that I couldn't get it for my son who's also a developer, just starting his journey. But then I found out that my Dutch son got it so that made it all. Okay, so Cedric do Dev, that's your thing. Sorry, not sorry. I know you're not sorry you shouldn't be. Tell me about yourself, what you do at Expo, that sort of thing.
Cedric von Putten (01:15):
So my name is Cedric. I work on Expo for a couple of years now. I think it's over four now. I have been working on plenty of things from customer success all the way to maintaining snack, doing CLI work buck fixing SDK, like doing research, a research tasks all the way to wherever help is needed. I'll jump in and it has been a wild but fun ride so far.
Jamon Holmgren (01:42):
Yeah, it's been great to get to know you over the years of you working at Expo. I don't know, you do some really cool stuff over there and it's always fun to chat. Thanks Alex. Not to be left out. So my middle name is Alexander so I guess you can be my British son. So tell me about yourself and what you do at Meta.
Alex Hunt (02:03):
Hey, yeah, I'm Alex. I am a software engineer at Meta on Reactive and I work on developer experience. That's the JavaScript tooling, metro debugging and everything in between. I've been there for two and a half years now. Yeah, that's what I do now. I love it. Used to be a React native engineer. I like being on the team, being part of it is really my dream job and so anything we can do to make React, react native better. I love working on,
Jamon Holmgren (02:27):
Yeah, well that's awesome. This has got to be incredibly exciting for you because this is like a big project that's shipping now and we'll get into all that in just a bit here. But I guess I do need to read our sponsor thing, infinite Red. My company of course we're Premier React native consultancy located fully remote in the US We have a team of 30 senior plus React native developers support staff have been doing this for nearly a decade. If you're looking for React native expertise, hit us up Infinite Red slash radio, that's a new URL. Don't forget to mention that you heard about us through the React Native Radio podcast. Alright, enough of that, pay the bills. Let's move on the topic. Debugging the debugger with Alex Hunt and Cedric Bon Putin. What I really want to set this up is we have the history of the React native debugging experience throughout the years and then we have the path forward and we're at this inflection point between the two and so this is a really good touch point to be able to talk about this stuff. And I want to start with you Cedric, because you've been talking about this for a while about why don't we just all use console dot log.
Cedric von Putten (03:35):
Well fun fact there are still discussion over this, but if you use consulted luck, you will soon still have to use the dev tools as logging looks like it's going to get removed from terminal. There are opinions on that one. Maybe it's a bit rough to start with that one, but in my opinion adding console logging is fine, it's fine, but it does add a lot of time to debug something or you can't really look into things without updating the code, which means you have to, well go into the code, edit it, refresh, maybe go through the whole thing instead of just adding a few break points and then inspecting all the information that is available right there. So if you just do a consult log, you can log a value, but what if you need to check what this specific functions returns? It is so fundamentally better in my opinion that if you have access to functions or the global scope or anything that you can do within the app itself, you can just code it. When I debug anything I go into the native modules manually and then invoke things manually to see exactly what's going on and where.
(04:59):
So it's a little bit more than just logging some text or logging some value. It's also invoking things and maybe work around some user interactions.
Jamon Holmgren (05:07):
Yeah, it's all about getting insight into what's actually happening and checking your assumptions. Usually when I'm beating in my head against the wall on some sort of a bug, I'm making an assumption about what's happening that is just incorrect.
Cedric von Putten (05:22):
Yeah, exactly. And those assumption, one time I had to debug something that was so out of reach for all of us. It was happening on EAS but only for specific projects using specific setups and there were five other factors. Being able to see the whole context and gather as much as information together to piece it or to gather enough information together to create this image of what you think might happening or put the puzzle or pieces together that is so fundamentally useful. I cannot, cannot have that. Not anymore. I need it for a lot of things.
Jamon Holmgren (06:02):
Yeah, totally. And I want to ask you Alex as well because obviously debugging tools matter. What's your take on that? Why don't you just use console dot log?
Alex Hunt (06:12):
Yeah, again, console log is useful. You think it'd be an easy question to answer. I guess console log only gives you a view on some of the system of what you've explicitly looked to show. We really want to provide tooling to let you understand the state of your app as it runs and see it in different ways, whether that's React dev tools, sources, panel break points, and these are fundamentally more powerful tools for things you might not predict upfront happening. They're just fundamentally more powerful tooling.
Jamon Holmgren (06:38):
I think as our applications get more complex, when you start out with hello world, you're just starting getting you're in university or you're learning to code, the types of problems that you run into tend to be honestly totally fine to use a console dialogue. There's not a lot going on so you can check these things as they go. And so a lot of times people get used to that workflow and then it just continues to build as time goes on where the applications we work on, the frameworks we work on, they get more and more complex as time goes on. And I don't know, react native itself is probably the most complex framework that I've ever worked on just because out of necessity because it's hitting so many different technologies and so many different platforms that it's trying to target and you need tools that are sufficiently powerful to deal with that. So I want to talk about what debugging looked like in the past. A lot of people listening to this will be maybe people who've been around from the beginning and know what it was like to deal with the debugging tools in the past and some people will be relatively new to React native and just coming in now and wondering what the state of it is and I want to ask you Alex on that, what did debugging look like in the past?
Alex Hunt (07:57):
Yeah, well we came into this problem that started 2023 and really it was all this fragmentation, a lot of historic fragmentation around what React native started out being and how it evolved and what it is now really for the topic of JS debugging, like step through debugging, we always basically pointed to whichever engine was inside React native at that point in time, whether it was JavaScript core or Jesse and Android and Hermes and said, okay, this is the August server now let's just see where how the JavaScript's executing connect to that, expose it somehow that will work. And we did that and we added more. We added fancier front ends to connect to it and
Cedric von Putten (08:34):
Then
Alex Hunt (08:35):
The flipper like, okay, let's have this adjacent plugin system that separately communicates and maybe does that you debug native stuff in a convenient way. We were just adding more and more onto the layers of the onion that is React native. And what we realized during 2023 was we really couldn't continue adding stuff even though we're excited to maybe build some new capabilities in fundamentally having debugging being hosted by the JS engine wasn't the right model and there'd been a ton of bugs and fundamental issues because of it and a lot that we couldn't build into the backend. That's what powers the debug experience to create something unified unless we really stripped it out and rearchitected it, which is what we took on for native TE tools.
Jamon Holmgren (09:19):
Yeah, that's a big job, but it's also Tbu is so important. This is something I tell newer developers who talk to me. They're like, what skills should I be learning and things? What frameworks should I use, et cetera. You can learn a lot of different frameworks. I've learned many over the years, I'll learn more in the future, but really you need those fundamental skills, especially things like debugging because I don't know if there are more frustrating moments in programming than debugging sometimes if you ask anybody what's your most frustrating experience? It's usually something like either setting up tooling and it doesn't work. So again, you have to debug that or your app itself or what you're trying to program is also not working and you don't know why and it's like you're hitting your head against the wall for four hours and I ran a company for 10 years now I've run this one for nine.
(10:15):
My previous company I had a lot of more junior developers that I was teaching and stuff. Many of them are now seniors at my current company, but they would be like, I can't fix this thing. And I'd be like, what are you doing to debug it? And they're like, well, I'm just trying stuff. I'm just trying new things to see what happens. And I'm like, no, let's take the time to set up some sort of insight into what's happening, whether it's just putting in some logs or actually connecting up a debugger, jumping into some sort of a rep. There's a lot of different ways to do this or even just having, sometimes I'll build a view into the app itself just to show some data, show something that's happening and usually after we set that up it becomes clear what's going on. So yeah, it's been extremely important.
(11:01):
And you're right, we had the Chrome remote debugger, we had a flipper, we had a bunch of different tools. We built React Theron back in the day and continue to maintain that going forward. Reliability is a big deal for React native, making sure your apps aren't glitchy and crashing and that sort of thing. This goes back to a lot of the reputation that React native has within the community. It's like, oh, can you tell it's a React native app? So I know that that was super important to make sure that the apps are reliable, but then we couldn't do that because the tools we had weren't even reliable. So I don't know what question I had there. I was just ranting a bit, but Alex, I'm sure you identify with some of that.
Alex Hunt (11:43):
Yeah, sure. I mean a lot of you're saying is let's align with the new architecture really that's
(11:48):
Rebuilding that native from the inside out to be more reliable, to be better architected, to make more sense to match what has become of the current scope of what it does and that we've figured out with program model at production ready, react native, and yeah, we took a super similar stance of des the rebuild was pretty much motivated by reliability and just fundamental correctness as well. If we're going to have creme dev tools be a front end for debugging the app, we need to model it the same way in the backend as Chrome does to really deliver on things, deliver on break points across reloads to deliver on a reliable connection to deliver on lay down the line extendability. So yeah, that's totally the philosophy behind it.
Jamon Holmgren (12:29):
And I do want to talk about CDP, the Chrome dev tools protocol more. I want to ask Cedric, I think didn't you mention CDP to me a long time ago?
Cedric von Putten (12:39):
Yeah, the idea of actually using CDP to debug React native came at least within expo years ago, I think just after launch of Flipper because before that we were actually using my favorite or not so favorite debugging workflow, which is the remote debugger that was fundamentally a bad idea, but you can always say that in hindsight I guess. But that was basically the start of actually using CDP for Reign native itself and there were a lot of good points there, but moving the whole engine through a different machine and then let Reign native inter or bridge the whole network layer, that's not a good idea. So we wanted to give it another shot a while ago, but then we never got around to it. That is until before fgs I think 2023?
Jamon Holmgren (13:39):
Yeah, last year. Yep.
Cedric von Putten (13:40):
Yeah, yeah. So right before that I think Kudo came with the idea of doing something different.
Cedric von Putten (13:47):
Then
Cedric von Putten (13:48):
We did some research and turns out that Hermes was actually supporting parts of the CDP spec, but as Alex mentioned, it was built as a house of cards where things were added but without a solid fundamental system, so things were a bit buggy. So we tried to work around a few of those really, really rough edge cases. We got somewhat far by no means a full coverage of everything, but at least for us it was way better than having nothing or having something else. Let's not name it by name. So there's all history there.
Jamon Holmgren (14:30):
So Chrome Dev tools, protocol CDP, we're going to be mentioning that a lot. It is essentially like a common protocol for implementing dev tools within a browser, usually for JavaScript inspection in particular, and I believe many browsers implement this. It's not just Chrome, right? That CDP has used in multiple places wherever there's kind of JavaScript,
Cedric von Putten (14:53):
There are a couple, not all browsers do the same. Some have their own variation on it but look somewhat similar. I think Oprah is one of them that has the variation on it,
Jamon Holmgren (15:04):
The
Cedric von Putten (15:04):
Safari
Alex Hunt (15:06):
Chrome Blink Fork from WebKit, right? So the one in Safari is a precursor CDP in a way
(15:12):
And Cedric's right in that all of the protocols debugging in every browser looks pretty similar, especially for the browsers based on chromium now. Yeah, it's all kind of historically inspired from the same thing and CDP is like this versatile communication mechanism to ask a browser, how are you running? What can I get from the page? What task can I ask you to do? Start a performance profile, even C'S quite cool and want to build on it because mature and it really is a standard that's evolved and can cover a lot of things, but it could even do things like we could ask the browser to control itself stuff like puppeteer does, and you can do that over CDP as well, like click around elements and interact and there's an exciting slide for my talk at Universe, which is with CDP, everything in scope for browser dev tools could be in scope, react native in the far future and stuff like that down the line could be really exciting
Jamon Holmgren (16:04):
And it keeps speeding into this idea that React native is in some ways kind of a browser. It's not really a browser, but it's kind of a browser. There's a reason why we're not using a browser. There's a reason why React native exists instead of just putting it into a WebView React native has many more sharp edges, but also it's just so much more powerful in a lot of ways and it uses the built-in UI kits and whatnot. For one thing, a fairly significant portion of the people coming to React native are web developers and they're used to a Chrome inspector kind of experience. Let's shift gears into the debugger itself, the new one and let's talk about how that came to be and then how that was predicated on this web experience. Alex, I'll put you on the spot on that one.
Alex Hunt (16:52):
Sure thing. As like Cedric was saying around a similar time CDP had been used almost accidentally as the latent protocol because we were using JavaScripts as our language and it's like an engine aligned concept and yeah, it also became clear to us that continuing to use it made sense. Chrome dev tools, it is such a mature, rich, familiar experience web developers that has so many things out of the box really, and if you think of a React native app like the surface application level, it does line up almost exactly like a browser. I don't think we really coined it in that way when we started looking at this, but the familiarity point was really strong.
Jamon Holmgren (17:30):
Oh yeah,
Alex Hunt (17:32):
CCP interoperates with IDs as well. Dev to the front end is not the only front end. We could interface with editors like B Code, which translates to over DAP and that works out the box. That is how no debugging works out the box BS code. So we get all of that for free. If we double down on CDP, just we had this version of a CDP server that was incredibly bare bones. Not only did it only support a few domains and maybe step three debugging and logs inside those feature sets, it supported barely any of the coverage of available like rich methods that were there. And that in some cases that if you clicked around the front end it would make those requests and React native wouldn't handle it, so you might have buggy or missing functionality. So the starting point, even in 2023 was asking Hermes directly to say, Hey, could you patch some of these gaps?
(18:19):
And it made advances and we got features like persistent consult logs. It was the starting point in 2023. We tried to add a lot of stuff and get quick wins and it was later that year that we really decided we needed to down tools and go into rebuild mode. It just made sense and the result is what we have now. I think we actually did that in a remarkable amount of time and actually shipped the thing too. It's like a mini new architecture, but for the debugger that's amazing. It's been super fun and the whole team's learned loads doing it. We built it around Hermes as the first party supported thing and there are new interfaces. So right now reactive dev tools is built around and interfacing with Hermes and only support Hermes.
Jamon Holmgren (19:00):
Yeah, I think that makes sense. You only have so much engineering time, you can't solve every problem and you have more say in the Hermes side of things versus JSC, which is there's just more interested parties there.
Cedric von Putten (19:14):
To be fair, if you have your app running in JSC, just like for example a web view with Safari, you can actually just inspect that that's baked in. There is a tool for that already. It falls apart when you're actually using Hermes like the default re native engine. So the focus on Hermes here was extremely important and then the JSE support that's there already, but you have to turn it on in non-obvious ways.
Alex Hunt (19:42):
Yeah, it works pretty magically and quite stably from the stars. You said. JSC debugging is the only mode that we've left deprecated apart from the Nepals, so it still stays around.
Jamon Holmgren (19:54):
Okay, this might be a dumb question, but why not just make Hermes compatible with that?
Alex Hunt (19:58):
I guess because Safari dev tools is with the way the web has evolved more primitive and less extendable and it is not the protocol used for things like VS code. So yeah, Chrome really has become the web over the last at least decade and a half.
Jamon Holmgren (20:15):
Yeah, so that's
Alex Hunt (20:15):
The protocol to use.
Jamon Holmgren (20:17):
Yeah, totally. Crik really quick I want to ask, you'd been working on an expo debugger. What sort of led to you combining efforts with meta?
Cedric von Putten (20:25):
The start of our combined effort was actually AP just 2023. Alex did a talk there and I did a talk and then in the preparation phase we shared our talk titles and a little bit of an abstract and then turns out that Alex and my talk were actually pretty similar, so we're like, wait, what? And then we started chatting and after that, so fundamentally it is important at Expo
Cedric von Putten (20:54):
For
Cedric von Putten (20:54):
Our users to have a way to debug and with Flipper was a way, maybe not the preferred way, but with Hermes we felt that there was a need for something way better.
Alex Hunt (21:07):
Well yeah, exactly. I'm sure Expo completely beat us to integrating in one click of debug launch flow by at least six months or maybe a year. So for us that was a huge validator that works and people were willing to use that outside of Flipper even back then and what we imagined the debug game becoming was really aligned.
Jamon Holmgren (21:25):
I think it's awesome that you did combine efforts. It's not always easy to do because you have to sort of commit to a level of collaboration. You don't have quite as much just like, oh, I'm going to do this thing and you go do it, right? You have to talk to each other a little bit, but there are benefits too because more people aligned and pulling the same way and not reinventing the same thing over and over.
Cedric von Putten (21:46):
To be fair, the CDP sounds like a very complicated system, but in essence it is similar to how reactor tron works. You have a web socket and you have structured data going over
Jamon Holmgren (21:58):
It
Cedric von Putten (21:59):
And then the CDP is feature rich. Sorry.
Jamon Holmgren (22:01):
Yeah, no totally. We invented our own protocol for React Actron of course it's a much more limited subset Flipper. I want to talk about Flipper real quick. So Flipper was removed from the core experience of React Native Flipper did bring a lot of good tools. I wrote an article about how to replace Flipper within your stack. What I ended up recommending was go use the Xcode tools and use a lot of the Android studio tools and you're still going to need to do that because the React native debugger isn't necessarily going to give you insight into all of the native stuff and you're still going to need some way to handle that and I think when people think about a React native app, they think about a and app like one app, but it's really multiple. It's whatever platform you're deploying to and yes, the debugger and React trying anything on the JavaScript side of things is going to be focused on the part of the app that kind of works on more or less all of the platforms. But then you also have all the native code and whether you wrote it or not, it's still there. It's still running. How you envision the debugging experience? Do you see it more like people having Xcode open, people having Android studio open and learning those tools? Would your advice to developers be make sure you understand those tools a lot?
Alex Hunt (23:22):
Yeah, it depends the nature of the application you're building, say using Expo and you're using many of the well-produced expo modules, I'm working in that space on your product code. We'd hope that debugging at the React native level of abstraction is entirely what we need to do. Kind of network quests and data manipulation and view rendering is all there, but if you are starting write things that are more complex, adding native modules and actually writing pieces of the platform, layer yourself at those points. Xcode Instruments I Studio are absolutely the tools to use back on Flipper. I think with native dev tools we are what we need to do and we do start with a small feature set, but it's the discipline to offer more in this tool than was previously offered with just Chrome Metal's front end but not as much as Flipper and not work leaks outside the application browser model because we will never build tools that are as good as those specialized expert tools for each native platform. And at the end of the day, react native is native and if you are building up those layers or discover a bucket, those layers, the best tooling has been produced by those two major companies.
Cedric von Putten (24:33):
I fully agree on that one. It's like you are always left behind If you use something or creates something that mimics the first party tool from the company who made it themselves, it doesn't make a lot of sense to waste a lot of engineering effort onto that while you can actually use whatever the first party has to offer. That being said, it isn't always possible to use those first party tooling, right? Android studio should be able to run it on most machines, but if you have an old one, it might be hard to use.
(25:06):
And bring me to my next point. Xco doesn't work on Windows, but at Expo we do have a lot of Windows users, so we try to make it like optional where if you want you can go all the way into it or if you have the ability to, if you have a MacBook or Mac and you can run Xcode, you should be able to just dive into the whole all the way down to the instruction code almost. That being said, if you have native errors or if something is not compiling right, then it's likely that you have to go for Xcode or Android studio and then if you have a JavaScript side errors, those are super easy to debug with the React native dev tools, but if the native layer has issues you can't get to the Chrome, to the React native depth tools. If the native layer has issues, it actually might not work properly because of those native layer issues.
Jamon Holmgren (26:02):
I love how practical that take is. If you talk about this stuff on Twitter something you'll get people who are like basically everybody should do things the most maximum. You should always be using all of the full everything tools, the right operating system, everything and it's just not the reality, especially in emerging markets and whatnot. And why not build tools that are accessible?
Cedric von Putten (26:30):
Yeah, exactly. That's how Expo today basically works, right? Where we offer services to build your iOS app, even if you have Windows, we have Expo go where you don't have to build anything on a native layer, you can just use the JavaScript. So that's the idea of expo itself.
Jamon Holmgren (26:46):
So what are your favorite features of the new debugger? I'm going to start and I'm just going to say break points. Let's start there. Break points kind of worked if you knew what you were doing but now is just built in and some people listening won't even know what a breakpoint is. Some people will never have used a breakpoint, but in BS code you can click on the side like the gutter and a little red dot pops up and then when the app actually gets to that line of code, it will pause and be like, Hey, here, here and now you can inspect the state of what variables do I have and whatnot. Alex, what's your favorite feature of the new debugger?
Alex Hunt (27:25):
I'm going to ditter that just as a message to everyone. Please use great points or try them out. Imagine if you could get the stat trace to that error before it happens. If you suspect anything's going to happen upon your code, add a break point there and you've got all the context that it stops, your code was hit, you've got a panel with all the variables and scope the stack that's lit up to that and you can play around live at that point and you can even do conditional break points. You get into a context where you can see the whole surrounding application, whereas otherwise you might've made 10 speculative consult logs in the dark.
Cedric von Putten (28:03):
I was going to say conditional as
Jamon Holmgren (28:04):
Well. Conditional because one of my problems with breakpoints when I've used them on other IDs and contexts in the past is it's like the first pass through when it hits the breakpoint or maybe even the first a hundred are not the one I need. It's when it gets to this certain state, now I need it to stop and having the conditional breakpoint of when we're in this state now I want to break and figure out why it's wrong. Yeah, totally makes sense. Is that your favorite part of this or do you have something else? Well,
Cedric von Putten (28:34):
I was going to go for break points as well, but then to be original conditional break points, but now that has already mentioned as well see this is why I went first. Let's go for something totally different. I'm going to say the network inspector and the whole reason why I really like it is it was actually possible before, back in the days before reading native dev tools, but you had to set up this whole proxy basically you had to modify your whole system in order to check what kind of request your app is making and that's very common. Most apps nowadays actually use internet, not all but most log in somewhere or fetch some data from something. Having that available and visible to you with just J and then clicking on the network tab is insane to me.
Jamon Holmgren (29:25):
I'm contractually obligated to say that React Toron has had this for seven years. I wish I had fixed this a long time ago, but we didn't have a tab for it. It would just show up in our main timeline. You'd have all your network requests. If we just added network, it would've been amazing, but the fact that the debugger is going to be coming with it is huge. I agree. Network requests, that's one of the main reasons I'm jumping into the debugger is to look at what's being requested and why am I not or what kind of data am I getting back? Right?
Cedric von Putten (29:54):
The expo network inspector is actually a little bit deeper than that. We actually go into the native layer instead of
Jamon Holmgren (29:59):
Oh, you capture native ones as
Cedric von Putten (30:01):
Well. Yeah, so if a native request is being sent, we should be able to detect it as well. On Android it's a little bit harder because there is no primitive for that, but on iOS you actually have and that gives a lot of more lot more insight in how React native module might be working. There are plenty opportunities for improvements a lot actually. For example, how would a cached image that is normally loaded remotely, how would that show up in a network inspector as cached? It's like there is, there's no network requests.
Jamon Holmgren (30:37):
That's true.
(30:37):
Yeah. I feel like web developers who come to React native as opposed to native developers have a certain expectation of developer experience that's pretty high because we have all these cool tools like the ability to see, hey, this was just a cash hit and we didn't make a request that's just built in. You just expect it to work. I've been doing web for, I don't even want to say, let's see, it's like almost 20 years. It is 20 years almost. Yeah, about that and I've had, well I guess I didn't have inspectors back in the early days, but Firefox I think brought in something early anyway. Okay, I don't want to talk about the old days too much, but we've had it forever and a lot of this stuff native developers just deal with it. I want to ask Alex this specifically for you. Have you gotten feedback from developers who have used the new debugger and what's been the flavor of the feedback so far?
Alex Hunt (31:29):
The flavor of the feedback, we've internal external feedback. The internal side, it really is the story that there is one clear entry point to debugging and that it works. It works in every scenario we have internally and it works reliably. I think native engineers in particular don't so much come with the web develop expectations, which I have that you've got these rich high level features, but more that like is our break points going to work in this application? Can I debug the program back core functionality and having that work in a clear one to look entry point has been such an upgrade for our users that we have good feedback on that. We are going to collect more data with the state of reality native survey coming up hopefully,
Jamon Holmgren (32:07):
And
Alex Hunt (32:07):
Really I want to get some forward, forward-looking information there. We'll have free form questions for anyone listening in that survey to just please throw your opinion about what you want. Dislike would like to come, but yeah, open source. What we've seen so far is chatter or lots of feature requests too in constructive feedback. It's all mixed and internally as well. Internally people would love to see performance tooling get a lot better. An open source network panel is by far at the top of the list.
Jamon Holmgren (32:36):
I just have a curiosity question. Why are you even supporting the architecture? I would've thought that this would be a forward looking new architecture thing only.
Alex Hunt (32:46):
I mean at the point we began this and even at this point in time, imagine that we have lots of consuming apps am met. Not all of them are on the new architecture yet. To our scope selfishly from our CO with the team was we want to get off this fragmented tool into something that's reliable and that's levels up the development experience with React native for everyone at Meta and everyone and it happens to be a chunk of the code base where it's reasonable to do it for both architectures. So for a bit more engineering time, we got that working. We're able to also run our experiments internally against the maximum amount of users.
Jamon Holmgren (33:23):
Do you have any tips for developers who are trying out the new tools, like key features that they should try first? Other than breakpoints, which we've talked about
Alex Hunt (33:31):
The React dev tools panels are really great, so the components inspector and the React profiler. Big takeaway is that it works just like it does on web now in React native. Every feature of these panels from basic stuff like selecting and highlighting UI elements and changing props live almost like you can in the Elements inspector to the profiler, which really is the closest thing we have to why did you render answers or what is taking time? What is rendering? If you care about the performance of your React app, that's the best place to look right now.
Jamon Holmgren (34:01):
As someone who's working on the dev tools, do you get a chance to use them yourselves on actual apps and do you ever go, wow, this sucks in this one way, I'm going to go fix it. Or also like, wow, that was even more useful than I thought. That's pretty cool.
Cedric von Putten (34:20):
Well, for me, yes. When we were working on the first version at Expo, even before React native theft tools, I used the debugger to debug the debugger a lot. I joked about that as well. Then I used the VS code debugger to use, no debugger to debug the CDP integration of the debugger. I use the debugger to debug the debugger a lot basically.
(34:45):
And then of course every day I'm using it Right now we have a lot of tests, a lot of dark fooding and a lot of examples where things might just not work when you test cannery versions and one of them was actually the React confab yesterday, so KA and I were jumping on a call and just clicking through, we spotted the issues. There were some upgrading issues, some yarn V one related issues, but yeah, basically without the React native defiles it would've taken me like three days or something instead of just two hour on a call.
Jamon Holmgren (35:20):
That's amazing. How about you Alex?
Cedric von Putten (35:21):
That's awesome.
Alex Hunt (35:22):
Oh, I wish I had a good React native side project right now I don't really, the closest I've got to using dev tools is I found some great bugs in Chrome dev tools front end by running dev tools on that dev tools. Apart from that, gosh, using the BS code or Android studio debug is on actual native code this year. It's an essential, but it's not tools we're building. Just like Cedric's saying,
Jamon Holmgren (35:44):
It's tough because this is your main job. You're working on the debugger and using the debugger, you could get lots of insight into it, but that is you're more relying on people to give you feedback and tell you their experience and whatnot, which totally reasonable, but I think we need both types. I think we need people who are really deep in the internals, like what you're doing, Alex and your team, and then we need people who are using it every day and also being willing to communicate that in a way that is constructive. Of course people are working on this and they're probably aware of the issue. Well, I'm really excited about, I thank you both and everybody on your teams for the work and the investment that you're putting into this because I think this really does make my life easier. It makes my developers' lives easier, my client's lives easier, it makes for a better, I think it'll make for tangibly better react native apps as well. The ones that actually hit the app store are going to be better because of this. Before we end here, where are we going with this? What's next for the debugger
Alex Hunt (36:47):
With this rewrite that we've done quietly and within our team and we kind of rebuilt everything and built the basic features back out again, really like break points, but we didn't build more advanced features are highly requested features, so we're immediately going to build upon this new platform base and give users very useful other core tooling from web starting with the network panel. So we're absolutely investing in that. Internally we have a focus on performance tooling, so we're going to explore how we can set up an official profiling, build flavor of React native and deliver features of Chrome's performance profile performance panel or a subset of it with browser like stats for React native and maybe after that explore our performance tooling that maybe aren't expert tools like what could we ambiently detect and automatically flag to users at least maybe that's a research area for this year.
(37:39):
And another big thing we want to hit is see if we can bring first party fierce S code into a better place. This code has mentioned support CDP, but it targets the node backend and also behaves a little differently than Chrome's frontend does when interacting with us, particularly around source maps and where files come from. The files are in the editor you'd think, but it's resolving that whole two of things. So we want to make this code support great and there's no timelines in any of these things, but we're at least definitely working in those pieces, which hopefully emit things we shipped to open source over time. But the network panel is definitely a top priority for what reaches open source.
Jamon Holmgren (38:19):
All of that sounds amazing. Obviously that's going to be a lot of work. Cedric, where are you at with this?
Cedric von Putten (38:25):
Yeah, so I mean I fully agree or mostly meta rework the whole fundamentals, but now it's time to step out of it I think or not too fast because it still needs to be built right, but step out of the absolute core basics and into the more feature set that Flipper had or any other debugging tool. For me, my stretch goal is still to remove the biggest pain point or one of the biggest pain point of Reign native from the State of Reign native survey. I want debugging gone there. Wouldn't it be great if we had the actual element inspector as well? Those kind of things. But for that we do need to have fundamentals available to us to be able to implement it and that's the first next step I would say. And then we'll see where we can get it.
Jamon Holmgren (39:16):
I'm going to make an executive decision here and extend this even more because I have this question that I think is important. What do you see as being the role of other debugging tools such as React Toron, react native IDE, and others that exist out there and that probably won't be going away and combine that also with do you intend to add a plugin architecture?
Alex Hunt (39:38):
Sure. Well other tools beginning with React native or Raydon as its now named or V Code Expo, these are extended versions of VS. Codes debugger and they are front ends for which they benefit from the new React native dev server. So they fit in completely we'll continue to build a stronger and stronger backend and they should work perfectly. Tools like React Tron if they want to offer additional other tooling that's not in the CDP Surface can totally do that and totally be a separate entry point that's opened for that purpose. Some purpose in between the low level native debugging and what we at Native De currently offers. But yeah, then on this kind of aligned with web extensions area, this has also been a highly requested feature like
(40:24):
Other previous debugging projects have offered the ability to have useful Chrome extensions as Deb plugins built in those people at native debugger with Apollo and Redux dev tools and relay dev tools for us, there's absolutely a use case for supporting Chrome extensions and expos got really good prior art in that they've got the expo dev plugins set of packages where you can bootstrap and run these separately and that really validates the user demand and use case for us as well. So yeah, we said we are beginning to look at extensions in a reasonable priority with Expo is a key partner there. I'd say own extra. It's mostly going to be from the research side, deciding if we can offer a good very well scoped API where the scope is, if the extension communicates with the main JavaScript context, it's valid. If you have an extension that's some front end that is trying to get outside of CDP, that would be the counter example. Very much something we wouldn't want and something that would, that's what Flipper was doing high level, we'd like flip extensions, need to design them very carefully. It'll sit somewhere for us to interface with expert with during next year.
Jamon Holmgren (41:37):
Yeah, I agree because once you have a plugin ecosystem, it starts making things harder to change because now you have a bunch of plugins you're probably going to break if you make any changes that sometimes are very needed. So I would absolutely support this cautious and a very deliberate approach. That totally makes sense to me.
Cedric von Putten (41:58):
There are always specialized tooling, different kinds of tooling like React Toron that has a more ergonomic way of debugging or creating a feature set to debug with basically you can create your own group of features purely for debugging for specific teams. That's a more specific tool to debug with and vs. Code is the same vs code is literally next to your code. You literally add it with it, but it does not have a network inspector, so there are always room for other dev link. This is just a general purpose tool.
Jamon Holmgren (42:38):
Yep. Thanks so much both of you. I know there's way more we can talk about seriously, we keep going another hour, but I really appreciate both of you coming on talking about all this stuff. Where can people find you online to follow progress on this, Alex?
Alex Hunt (42:52):
Well, yeah, for progress on this. So follow me. I'm on X as Alex Hunt without the vowel. So A-X-H-N-T and the release of reactive devs actually comes with a discussions post. So if you search for 0 7 6 React native dev tools discussion, you're likely to reach that. If you go to the docs or the blog for React native seven, six, you'll see the announcement and the coverage of base features that come with React native dev tools.
Jamon Holmgren (43:18):
Awesome. Cedric, how
Cedric von Putten (43:19):
About you? You can follow me on Twitter Cedric Dev, but also on the other Blue Sky ish app. It's Cedric Dev. Yeah.
Jamon Holmgren (43:31):
Yeah, thanks a lot. Of course, you can follow me at Jamon Holmgren or on Blue Sky jamon dev and you also can follow the podcast react native DIO on Twitter. A special thanks to our editors because they're going to be spending a lot more time on this one. And as always, see you all next time.
Jed Bartuasky (44:02):
As always, thanks to our editor, Todd Werth, our assistant editor, Jed Bartausky, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Heinze and Mazen Chami. Thanks to our sponsor, Infinite Red, check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.