Replies: 10 comments
-
|
I think the debugging in Node would be cool. I'm guessing that would mean you could use the Node in an Electron app (ie, React Devtools) to do the debugging which could allow developers to build some pretty powerful debugging interfaces |
Beta Was this translation helpful? Give feedback.
-
|
Not really use Node in electron. I just mean that instead of JSC, the JS code will run on Node, and debuggers could be attached to Node. |
Beta Was this translation helpful? Give feedback.
-
|
Would it really be "Node"? Wouldn't it be more like just using V8 directly as the VM, like NativeScript does? "Node" implies a whole set of runtime environment and builtins that we wouldn't want. |
Beta Was this translation helpful? Give feedback.
-
|
But I also don't see a great reason to use V8 instead of Chakra if Microsoft is going to get Chakra working anyway for windows. |
Beta Was this translation helpful? Give feedback.
-
|
With 2) having the bundle running in NodeJS is super cool 🙃 have been doing this myself for quite some time now to e2e test native modules with JS code coverage. But, I do believe 3 would be better and a more realistic environment. I remembered software mansion had an Android repo that had JSC debugging for RN - https://github.com/SoftwareMansion/react-native-android-jsc-debugging - if it helps as a reference for anything. |
Beta Was this translation helpful? Give feedback.
-
|
cc @RSNara |
Beta Was this translation helpful? Give feedback.
-
|
I believe that debugging the code into the device itself is the best option. There are differences between Javascript platforms, such as Node and JavascriptCore. I see this every day I am trying to debug RealmJS. Debugging on the end device is the best approach, in my opinion. The fact that the Android JSC runtime is pretty old should not be a show-stopper - it should be upgraded either way in order to properly add 64-it support (and other features such as Proxy objects etc, which are used by Libraries such as Mobx 5.x). Edit. before you decide, read this: To be honest, I switched to Haul a while ago. Debugging in Safari was a breath of fresh air for me, since the JS code runs in the device and not in my browser - and I can debug it there. Using Node is a step back in my opinion. It will provide a hack, but this kind of short term decisions are the ones that got us talking about switching debugging methodology in the first place. I believe we should solve this once and for all and provide a way to debug JSCore in the device. |
Beta Was this translation helpful? Give feedback.
-
|
Heads-up, the new JSC landed on master so the main blocker for option 3 I think that now is "gone". commit -> facebook/react-native@f3e5cce |
Beta Was this translation helpful? Give feedback.
-
|
I believe that the only major barrier to using Safari Debugging is the lack of sourcemaps. We might be able to fix that by including inline sourcemaps for dev builds? This project also has a good example of how to bridge from the JSC debug protocol to a Chrome compatible one (and hence VSCode and others): https://github.com/RemoteDebug/remotedebug-ios-webkit-adapter/ |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible to achieve debugging experience like native debugging?using chrome need open a chrome window,I think it is unnecessary,I just want to debugging in vscode or any other IDE. |
Beta Was this translation helpful? Give feedback.
-
What
The ability to attach to JSC directly to debug React Native JavasScript code.
Background
Currently, we use Chrome to run the JS code when React Native is in the debug mode. When we start the debug mode, a new web socket connection is established via the packager to an instance of Chrome. We then use Chrome developer tools to debug the JS code. Similar mechanisms are used in the VSCode debugger for React Native, and the Idea react native plugin.
Why
When Native Modules today use a synchronous API, Chrome debugging fails. Sync API for native modules are not common, and at many places, such module provide alternative async calls.
With Fabric, there would be many more cases that utilize the synchronous API. Fabric will also use the new JavaScript Interface (called JSI), which lets JavaScript hold references to C++ objects.
Both these cases may not debuggable with the current setup.
How
There are currently two possible approach to support debugging in the future for OSS React Native projects.
Support Synchronous debugging in Chrome. For this, whenever we move over from WebSockets to Sync-XHR whenever a synchronous API is encountered. This could be slow, and may not support the concept of Host Objects.
Use Node for Synchronous debugging - Currently VSCode uses this approach. Instead of starting Chrome, it starts up Node, and debugs node using the node debug protocol. Node has support for Synchronous HTTP/XHR, so this could be leveraged. We still need to see how JS holding references to C++ objects would work.
Debug JSC directly on the device - this seems to be the best approach, but may also require the maximum amount of work. Currently, Safari allows JSC on the device to be debugged directly. The JSC that we use in Android is pretty old and may not support debugging. We would need to find a good debugging story.
Side Note - We would also need to start supporting debugging Chakra in case of RN-Windows.
Beta Was this translation helpful? Give feedback.
All reactions