Confusing experience opening the Dev Menu

[elicwhite]

Just a bit of feedback coming from an iOS/Android world. I spent about half an hour trying to figure out how to get the dev menu to come up. In the end, I feel silly because it is as simple as right clicking. 😅

I figure it is worth sharing my process though just in case there are opportunities to widen the pit of success for people onboarding in the future.

• I first tried focusing the RNMac window and pressing CMD+D because that's what brings up the menu on iOS.
• I then went to look through the docs at https://microsoft.github.io/react-native-windows/docs/getting-started to try to find some mention in the getting started guide.
• I then went deep and tried to use the metro websocket connection to try to open the devmenu. This is something I know metro supports because we use it at FB but isn't part of the CLI. So I modified https://github.com/react-native-community/cli/blob/master/packages/cli/src/commands/server/runServer.ts#L124-L127 adding the lines below. The server responded 'OK', but no menu opened in the app.

    .use('/devMenu', (_req: http.IncomingMessage, res: http.ServerResponse) => {
      ms.broadcast('devMenu');
      res.end('OK');
    });

• I then right clicked and there we go, a dev menu! lol

---

As a heads up, the Flipper support that comes by default in 0.62 has a menu bar for React Native that has buttons for reload and opening the Dev Menu that works by sending that command through metro above: https://github.com/facebook/flipper/blob/master/desktop/app/src/chrome/MetroButton.tsx#L118

You may want to think about how that experience will work on RN Mac and Windows in 62.

---

React Native version:

System:
    OS: macOS Mojave 10.14.6
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 126.43 MB / 32.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.16.2 - ~/.nvm/versions/node/v10.16.2/bin/node
    Yarn: 1.17.0-20190429.1820 - /usr/local/bin/yarn
    npm: 6.9.0 - ~/.nvm/versions/node/v10.16.2/bin/npm
    Watchman: 20200330.230017 - /opt/facebook/bin/watchman
  SDKs:
    iOS SDK:
      Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
    Android SDK:
      API Levels: 23, 24, 25, 26, 27, 28, 29
      Build Tools: 23.0.1, 25.0.0, 25.0.2, 27.0.3
      System Images: android-24 | Intel x86 Atom
  IDEs:
    Android Studio: 3.6 AI-192.7142.36.36.6308749
    Xcode: 11.3.1/11C505 - /usr/bin/xcodebuild
  npmPackages:
    react: 16.8.6 => 16.8.6 
    react-native: github:microsoft/react-native#v0.60.0-microsoft.40 => 0.60.0-microsoft.40

[kevinvangelder]

The short term fix might be to add verbiage to the boilerplate with instructions on how to open the macOS dev screen? That's what we did with React Native Windows.

[mgcrea]

Can confirm having encountered this issue. Having CMD+D working would be great as it's what is expected by existing react-native developers.

[tom-un]

We'll definitely add the devmenu support instructions in the docs.

Supporting Cmd+D is really not very straightforward at all on mac. Once upon a time when the fork was internal to Microsoft we did try adding a keyDown: event on RCTRootView and that worked. However, it requires RCTRootView to respond YES to acceptsFirstResponder. When we added key loop support, the root view must respond NO otherwise the root view itself is part of the key loop which is not at all desirable: the root view itself is an invisible part of the loop and when focus is on the root view and the user hits a key the system "boops". Perhaps RCTRootView could respond YES only in DEBUG. But that could be a confusing experience too because key loop behavior would differ on Debug versus Release.

Alternatives to the root view accepting first responder are not appealing: we could make the app be a global event monitor of keystrokes, but that requires the app being granted "Input Monitoring" access in System Preferences > Security & Privacy. The app could use an old Carbon API, InstallApplicationEventHandler, but using Carbon precludes apps from being in the Mac App Store. The Carbon API usage could/should be DEBUG only allowing code to be in the App Store, but using the InstallApplicationEventHandler is global to the app and could clash with host native app usage (unlikely) but more interestingly the implementation in RN would have to be fairly smart to handle more than one RCTRootView in the app. Office, for instance, can have several instances running including background instances: how do we determine which instance to target the devmenu? Maybe a SplitView with instances on the left and devmenu choices on the right?

So, we need to support the 'devMenu' server command as @TheSavior described above. It could invoke the current NSMenu popup implementation.

[github-actions]

This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.