How I Hacked React Native DevTools (And Built a Plugin Framework)

Hi, my name is Simon, and I'm here to talk about how I created a custom React Native DevTools plugin framework you can install from NPM and use in your day-to-day work to load the custom plugins, like, for example, Tasked and Query DevTools, so you can use those inside of React Native DevTools. I don't want to basically advertise the tool. I want to show you how I created it, what was needed to make it work. So before we start, let me describe why we need things like this.

So back in the days, there was Flipper, which was basically a different DevTool you could use to, well, work with your React Native applications. Flipper was great because it allowed us to build custom plugins and load them inside of Flipper, so then we could, for example, have Redux DevTools available to be used in day-to-day work. The problem is that Flipper was not great when it comes to stability, and there were some problems with, for example, connection being lost silently between Flipper and the device.

So probably because of that, Flipper was announced as deprecated. So from some time now, we cannot use Flipper anymore because, first of all, it's deprecated, and second, the code necessary to communicate between the device and Flipper is gone from React Native. So effectively, Flipper is dead now. We have React Native DevTools, which are great, which are stable, which offer, well, super experience for developers, but we cannot use any plugins. There is no support for them yet. The work on them is ongoing, but basically we are not there yet.

So we need some temporary solution we can use for this time where there's no official support. And if we don't have any plugins, then we can say we are back at Dark Ages because we need to console log everything, ending up with a huge amount of logs, and then we need to inspect them, go one by one, looking for any problems. And you must admit it's not the best developer experience. So that's exactly why I created Rosanoid, so the custom React Native DevTools plugin framework you can use to create plugins and to load plugins into the aforementioned DevTools.

My name is Szymon Chmal, and I'm a React Native expert at Callstack. I'm a web developer by heart, but recently I switched to be focused more on cross-platform development, on mobile development with React Native. I love sharing knowledge via conferences, meetups, or just writing articles, for example. I'm contributing to developer tooling at Callstack Incubator. This is a special group of people at Callstack working on basically... Well, we are playing with technology and we are trying to push forward as much as possible. And I'm the creator of both Rosanoid and the recently announced React Native Harness, which is a new testing framework for React Native. And I'm coding from Toruń, from Poland, so the city itself is known for gingerbread and being a home of Nicolaus Copernicus in the past.

Now, before we dive into the code, we need to understand what are the constraints of our custom DevTools framework plugin, custom plugin framework for DevTools. First of all, we don't want to fork anything because we don't have capacity to maintain any forks and to, for example, synchronize the changes between the upstream repository and our fork. We don't want to block users from using React Native DevTools if our custom framework fails to load. So our changes to the infrastructure should be minimal. If any plugin fails, the whole thing, the whole DevTools UI should still work correctly. Again, to not block users from developing.

We need to implement plugin in a way, so people will be able to use React to implement UIs of plugins because they are React Native developers, so React is, well, like, the thing they use every day. And last but not least, we should reuse the existing communication link between the device and React Native DevTools. Why? We will learn about the advantages of this approach in a minute. So let's start with some facts about React Native DevTools. So you may think that React Native DevTools are basically a native application running on your operating system, let's say. It's not true. It's basically a web application that's being open in Chrome with a hidden header, with a hidden toolbar so we don't see the URL. But you can access the URL, and then you will see it's basically a local host server hosting the UI under debugger front-end path.

The UI, the code of it, is available on GitHub, so you can always go to the GitHub repository to inspect the code. And the bundled code is also shipped via npm package and then loaded on our site via Metro. And Metro is the custom bundler used by React Native. So basically there is a custom middleware embedded into Metro, which takes the npm package I just mentioned, reads it, and then serves it to the user on request.

When it comes to DevTools protocol, the communication link, we want to reuse the existing one, which uses Chrome DevTools protocol. Why? Because, for example, if we inject our communication, our messages into this link, we will then be able to debug two devices at the same time, which is not really straightforward if we create a custom link. And this is the thing that many, many custom DevTools struggle with, because there is no simple way to differentiate between devices. It's possible for React Native for their internals to achieve that, but not possible or it's hard from the user land to achieve the same thing.

Our plan is as follows. First we need to force React Native to launch the custom URL, so we will be able to serve a custom UI. And then if we achieve that, we can inject some custom JavaScript code, and that's our plan for the step two. Within this custom code injected to the DevTools UI, we want to use the existing API in the DevTools to create a new panel and display iframe in it. And then last but not least, we want to tap into the existing communication layer and send messages back and forth between the device and DevTools UI. As for the URL, we need to find the place where this URL is created.

So I dive into the code and I see this getDevToolsFrontEndURL function, which exists in the React Native dev.middleware.ut.getDevToolsFrontEndURL. And as you can see, there is this app URL constant, which includes our debugger frontend. We want to switch from debugger frontend to some custom text. In my case, it will be Rosenite. And as you see, this is basically a module and this function is exported from this module.

So the plan is to use monkey patching to basically wrap the function with our custom function and replace the debugger frontend with Rosenite. This is a hack but the only one needed to make the whole thing work. First, we need to require the module by absolute path to not be constrained by any encapsulation rules. Using the original function first, we call it with all the arguments passed by the caller, then replace the debugger frontend segment with our custom Rosenite segment.

Next, we need to inject the custom middleware to serve our DevTools UI from a different URL. Metro accepts a configuration property called enhanced middleware, allowing the injection of a custom middleware to serve static HTML, JavaScript, and dynamic elements. By creating the middleware, applying the monkey patch, and opening React Native DevTools, we can see the custom URL in use, and the DevTools will function correctly, enabling the move to the next step of injecting a custom script into the HTML.

So we call it first with all the arguments passed by the caller. And then we replace the debugger frontend segment with our custom Rosenite segment. Then the next thing we need to do is to basically inject the custom middleware. So we will be able to serve our DevTools UI from a different URL basically. And this is achievable because Metro accepts a configuration property called enhanced middleware. And with this property, you can basically inject a custom middleware, which in our case will serve the static HTML and JavaScript plus some dynamic things in the future.

After creating the middleware, after applying the monkey patch, when we open React Native DevTools, we will see the custom URL being used and the DevTools themselves will work just fine, which is great and which makes it possible to move to the next thing. So injecting a custom script into the HTML. This is a basic web application. There's an HTML file, which is an entry point, and there you can see there's a script tag including the entry point, but this time in JavaScript form. What we want to achieve is basically a secondary script tag, which will load our custom JavaScript entry point. And we won't replace the whole thing out with our custom HTML file.

Why? Because it may be said that in the future, some part of it will be changed. And that's exactly what happened when React Native 0.81 was released. And users started to create issues in Rosemary repository showing this. What happened is basically some script tags, or sorry, link tags loading CSS files were added and the whole CSS structure was changed. So as I was serving the old file, but with my change applied, I technically removed the link tags and that caused the UI to look like this. So we want to be better. We want to apply this change only to the latest version of the file. Plus, we want to do it in a way so we will minimize the possibility of such things happening again in the future. The new idea, the new approach is to load the file at runtime when the file is requested by Chrome, and then add the custom script tag after some element that's known to be always there in the HTML file.

Plus, we want to do it in a way so we will minimize the possibility of such things happening again in the future. The new idea, the new approach is to load the file at runtime when the file is requested by Chrome, and then add the custom script tag after some element that's known to be always there in the HTML file. And in my case, I'm using the body tag because there's always a body tag. And it's okay to add a script tag just after the body. And that's exactly what's happening there.

Then we need to gain access to the DevTools UI API. So we need to be able to create some panels, some custom panels, some custom tabs, and then the iframe. So we will be able to display any UI we want. So if we dive into some code that's been bundled and has been published as an npm package, you will see that there are import and export statements, which is important because normally when you bundle your web app, you end up with a module system replaced by, for example, webpack or a vid. And in such case, you cannot really, or it's hard to import such modules in your custom code. But with import export statements, we can basically copy the code, copy the import statements into our custom JavaScript, and they will be resolved at runtime just like that. So we will gain access to all the classes exported from modules from our custom JavaScript code.

After a long time, I found that there is this inspector view, which is responsible for basically holding all the tabs or the panels and displaying them. So in this class, I found two methods. One of them is super important for me because it allows me to add custom panels. So bypassing a view instance. So then I started looking for a view somewhere in the code, and I found that you can create a custom view by extending a simple view, which does nothing under the hood. So I create a plugin view, which basically creates an iframe, and this iframe is displayed in the contents of a view. I also added some event listeners. So we will talk about it in detail in a minute or two. But basically to provide the communication link between the plugin itself and the host. So DevTools UI, my custom code. So the plugin will be able to communicate with the device via the host. And after that, after all those changes, we can see this beautiful screen.

Of course, it's not included in the DevTools yet. It's basically a remote URL displayed as a panel inside of an iframe. But it's something. Starting from this point, technically we can display anything we want because iframes are basically Chrome instances, but embedded into different Chrome instances, right? So now we can start working on plugins. And we need to understand that plugins are composed of two parts. One part is working in React Native and one part is working DevTools UI. So the part working on the React Native side doesn't need to be bundled because Metro will handle that for us. We only need to switch from TypeScript to JavaScript, but that's easily doable via TypeScript compiler.

However, the DevTools UI, the state of things is different there. We need to bundle the code with some bundler like Vid. We will end up with HTML and JavaScript that can be loaded into Chrome without any issues. And for example, Vid is a perfect tool for that because Vid supports things like Tailwind, so people authoring the UI for their plugins can use Tailwind, which is great. And then the last part missing is the bridge, the way to communicate from the device side with the DevTools UI and the other way from the DevTools UI to device. And the problem is that this bridge needs to work on both sides where environment differs significantly. But before we dive into the exact differences, let's look at the interface.

So the client is pretty much simple. It has methods for sending and listening for messages. And there's a custom hook which returns null by default, but then when connection is established between React Native DevTools and the device, it will return a client instead. And now getting back to the problem of isomorphism. So we need to use different logic for sending messages and for listening for them on the device side and on the side of the DevTools UI. So what I did is basically I inject a custom global when I'm building a plugin UI, so then in this plugin bridge, I can check whether this global is present. If so, then I know I'm working on the DevTools UI side and I can use different logic for sending messages. If there is no such global, I know I'm working on React Native side and I want, sorry, and I can use the bindings, the global methods provided by the React Native environment. On the contrary, when I'm on DevTools UI side, I need to use the postMessage API so we can pass message from the iframe to the host and the host, our custom JavaScript, will listen for any messages coming from the plugin and it will forward them to the device which will basically establish a link between both parties.

And now it's time to see what is possible to achieve with such setup for plugins and for injecting custom panels and basically all the things we did. So this is network activity plugin which is an official plugin for Resonight and as you can see you can inspect your network activity. You can, for example, inspect headers. You can inspect responses and if a response is of JSON type, then you can interact with the JSON tree. You can collapse certain sub objects or expand them. The same applies to request bodies.

The whole plugin, the network activity plugin supports HTTP web socket and server side events plus it allows you to filter things, for example, by path. So you will end up with just a small list of requests. So yeah, all of this made it possible to create Resonight which is a framework for custom plugins basically for Reactivity DevTools. Resonight allows you to build frameworks. It will make sure they are built correctly so you can load them in Reactivity DevTools. If you install any plugin, Resonight will automatically discover it and run it.

It works with pretty much every combination possible when developing React Native. So it works with React Native CLI plus it works with Expo, Metro and Reapak and it comes with a set of official plugins you can use in your day-to-day work. Sorry. If you want to learn more about Resonight, you can always scan the QR code visible right now on the screen and it will lead you to the documentation page of Resonight where you will find, for example, a quick start guide. So you will be able to install Resonight in a single command in a matter of seconds. In case you have any more questions about Resonight, about anything I said during this presentation, feel free to reach out to me. You can reach out to me on X, you can reach out to me on LinkedIn, you can reach out to me on the Discord channel for Resonight, which is present on ColdStack's Discord server, which you can join via the link present on the Resonight documentation site. So that's it. Thank you for being with me and I hope you learned something interesting today. See ya.