The original address: blog.nparashuram.com/2019/10/deb…

Blog.nparashuram.com/

Release time: October 4, 2019

React Native has a great developer experience, and the debug workflow is at the heart of the workflow. Today, we’ll use Chrome to debug JavaScript in React Native apps. In this blog post, I’ll explore another way to debug workflows using Safari.

How does debugging work today

To start debugging, we open the Developer menu (using Cmd+D) and select “Debug with Chrome”. This action tells the Metro wrapper to open Chrome and the JavaScript code now runs on Chrome, not the device. Metro’s Web socket connection between Chrome and the device/emulator is responsible for passing the JS command to Chrome and sending the result of the statement back to the emulator.

The problem with using Chrome as a debugger

The whole debugger setup is clever because it brings the classic Web development workflow to mobile. However, there are several problems with this setup

  1. The JS virtual machine running on the device is JavaScript Core (JSC), which is different from V8/Chrome in debug mode. These DIFFERENCES in JS virtual machines can lead to bugs that are difficult to fix.
  2. Communication in debug mode occurs over network sockets, which are asynchronous in nature. This creates problems in cases where local modules expose synchronization apis. This problem only arises when Fabric and TurboModules are larger, because they have more methods of synchronization.
  3. Many developers currently use the JS Profiler in Chrome to understand the performance of their React Native applications. These profiles are inaccurate because they have that Web socket layer, introducing a level of network latency that doesn’t exist in real applications.

Use Safari

Originally, Safari can be used to connect to applications running JSC. For React Native applications, you can use Safari to debug JavaScript and use workflows such as setting breakpoints, checking variables, etc. However, the JSC debugger in Safari does not use a network stack, which means the Sourcemap URL in the index.bundle file is not evaluated, leaving us with a huge JS file to debug.

To solve this problem, a single line change in the appdelegate. m file enables the inline source diagram.

In the file sourceURLForBridge, replace the return [[RCTBundleURLProvider sharedSettings]… with the following.

[NSURL URLWithString:[[[[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil] absoluteString] stringByAppendingString:@"&inlineSourceMap=true"]];

This line simply appends an inlineSourceMap=true, causing Metro to return Sourecmaps in the index.bundle file. Once set up, Safari can successfully recognize SourcecMaps and open the source file correctly.

www.youtube.com/watch?v=GrG…

Next steps

Note that this method works for the emulator but not for the device. Now that we have Safari working, I also want the JS Profiler in Safari to give us accurate JS execution information, which should help improve the performance of the application.

Translation via www.DeepL.com/Translator (free version)