Add device.reactNativeDebugRemotely(bool)

[Salakar]

Description

Would love to be able to toggle JS remote debugging programatically via the detox device api - much like device.reloadReactNative(). My use case is as discussed here: #470 (comment)

What are your thoughts on adding in this functionality? Is this something you'd be against, it should be fairly trivial change wise and I've curated and tested the snippets required to toggle it on each platform if it helps.

I could attempt to PR it - but might take me a while compared to someone who's familiar with the detox code base 🙈 - but if not I'll give it a go 😛

Proposal api: - ?

await device.reactNativeDebugRemotely(boolean);

---

Android - Programatically toggle debugging

getReactNativeHost()
    .getReactInstanceManager()
    .getDevSupportManager()
    .getDevSettings()
    .setRemoteJSDebugEnabled(true); // or false

Tested and confirmed this in my MainApplication.java -> onCreate override.

---

iOS - Programatically toggle debugging

import { NativeModules } from 'react-native';

// only on iOS
NativeModules
    .RCTDevSettings
    .setIsDebuggingRemotely(true); // or false

Which resolves to this native code here: https://github.com/facebook/react-native/blob/master/React/Modules/RCTDevSettings.mm#L298

---

[LeoNatan]

I cannot say I am really inclined to like this proposal.

We've had issues with reloadReactNativeApp() as it is. Adding more RN-specific API usually entails supporting it in a very moving target. The snippets provided are JavaScript code, but the client side of Detox is native only. We do not inject JavaScript in the client. And RN native changes a lot.

Also, what is the use-case here? We had a request for something in the area of this functionality, but that was from FB RN-core developers. They wanted to test the dev menu itself, so we added shake support to the device API. But what is the use-case for remote debug?

[Salakar]

@LeoNatan my original issue description does include the native code though for both platforms and also my use case as well 🙈

I do get the hesitation around additional RN functionality though as RN internal APIs seem to change every release. I've had issues myself with the reload functionality being flakey and had to swap it out for react-native-restart internally for the time being until I can debug.

I think with a couple of people keeping on top of the RN releases this should be ok to keep these sorts of features going - something I can assist with?

[LeoNatan]

Sorry, I missed the link to the comment.

Would you like to work on a PR for this feature?

[Salakar]

@LeoNatan ye sure I can give it a go - just wanted to make sure it was something you guys would consider before I invested the effort into PR'ing

[LeoNatan]

We are still considering how to handle community contributions properly. We don’t want to reach a place where we’ve accepted requests but then there is no one to support these features after the fact. Before you start work, let’s see what @rotemmiz has to say.

[Salakar]

@LeoNatan If it helps re support - it would be a fundamental part of our testing suite for react-native-firebase so would be something I'd be invested in helping to keep it working. (our new WIP testing setup with bridge + detox is here)

[LeoNatan]

Such a commitment does help a lot, thank you!

Another issues worth considering is if the RN remote debugging works in release build. We normally recommend running Detox on release builds because they are closer to what the user experiences from an app. But release builds do not use the packager, which I think is necessary for remote debugging. I could be wrong.

[jaceofslades]

This is an issue we're dealing with at the very moment is that with a number of changes to our API, remote debugging would be very useful in order to verify that our mocks match what would be returned by the API.

[LeoNatan]

There has been no traction on this, and as I said before, I don't see us implementing support for this. Closing. If a PR is submitted, we will be willing to consider.