If you’re like me, when you saw how easy debugging React Native applications was, you were mind-blown. Setting breakpoints in Google Chrome to control your iOS device seemed like magic and sorcery.

But if you’re like me, you also distrust magic in programming. Magic must be understood so that it turns into engineering fact & competence. This article attempts to demystify React Native Debugging so that you understand the technical details behind it.

tl;dr

Here’s the jist

• A NodeJS server, called Packager, is started up in a terminal.
• Google Chrome opens up and loads your React Native JavaScript from Packager as a normal <script> tag. Note that the React Native application now sits in the browser with full debugging support. …

**THIS IS A DRAFT PUBLICATION AND IS NOT COMPLETE NOR GRAMMAR CHECKED**

In this article I go a little under the hood in exploring React Native’s Network Protocol. I use the word “Protocol” loosely here, because I don’t believe the current network traffic conforms to any spec per say, but is just a implementation artifact of the current state of the code. In fact on a cursory look, the traffic patterns between React Native 0.4.x and 0.8.x look different. So with that caveat out of the way, lets begin.

Viewing the Network Traffic

The traffic pipeline we will be inspecting specifically in this article is the WebSocket traffic between the NodeJS server sitting on the desktop and the mobile client. See my article React Native’s Execution Contexts to understand where in the pipeline were inspecting the traffic. …

Debugging React Native is really easy. But what if you want to debug React Native’s Packager?

Use node-insecptor

node-inspector & node --debug-brk ./node_modules/react-native/packager/packager.js

It will give you an output like so

Debugger listening on port 5858
Node Inspector v0.11.1
Visit http://127.0.0.1:8080/?ws=127.0.0.1:8080&port=5858 to start debugging.

Once you visit the URL above (and hit play on the debugger), you will get full debugging support

I’ve been working on a React Native project recently and came to the point where I needed to setup a testing framework. To accomplish this, I needed to deep-dive into React Native’s asset pipeline and runtime environments to better understand what’s going on behind the curtains.

React’s Runtime Environment

As most developers know, React Native will either run your Javascript code on a server on your computer (during development) or it will run the code on the phone itself in production environments.

But how it gets a message out of native code and into Javascript code is both interesting and complex. …

Inspecting the underlying communication traffic between React Native’s Javascript engine and iOS code can be pretty helpful when trying to debug what’s going on underneath the hood.

The best way I’ve seen to inspect this traffic is to turn on DEBUG_SPY_MODE in MessageQueue.js

var DEBUG_SPY_MODE = true;

or in newer versions of React-Native

let SPY_MODE = true;

Once turned on (and after restarting packager) you can then see the logs fill up with messages, like the following:

JS->N: RCTUIManager.createView([3,”RCTView”,{“flex”:1,”overflow”:”hidden”}])MessageQueue.js:488 JS->N: RCTUIManager.createView([4,”RCTView”,{“flex”:1,”backgroundColor”:”transparent”,”overflow”:”hidden”}])MessageQueue.js:488 JS->N: RCTUIManager.createView([5,”RCTView”,{“position”:”absolute”,”overflow”:”hidden”,”left”:0,”right”:0,”bottom”:0,”top”:0}])MessageQueue.js:488 JS->N: RCTUIManager.createView([6,”RCTView”,{“flex”:1}])MessageQueue.js:488 JS->N: RCTUIManager.createView([7,”RCTView”,{“onLayout”:true,”flex”:1}])MessageQueue.js:488 …