profile
viewpoint

microsoft/react-native-macos 1479

A framework for building native macOS apps with React.

HeyImChris/async-storage 0

An asynchronous, persistent, key-value storage system for React Native.

HeyImChris/fluentui-apple 0

UIKit and AppKit controls for building native Microsoft experiences

HeyImChris/fluentui-react-native 0

A react-native control library aligned with office-ui-fabric-react

HeyImChris/MSFT-FX-Playground 0

Playground for ramping up in Github

HeyImChris/react-native-macos 0

Microsoft fork of react-native

Pull request review commentmicrosoft/react-native-macos

macOS Keyboard Support

+/*+ * Copyright (c) Facebook, Inc. and its affiliates.+ *+ * This source code is licensed under the MIT license found in the+ * LICENSE file in the root directory of this source tree.+ */++#import "RCTViewKeyboardEvent.h"+#import <React/RCTAssert.h>++@implementation RCTViewKeyboardEvent+++ (instancetype)keyDownEventWithReactTag:(NSNumber *)reactTag characters:(NSString*)characters modifier:(NSUInteger)modifier {+  RCTViewKeyboardEvent *event = [[self alloc] initWithName:@"keyDown"

Should this be a constant? Isn't it duplicated in RCTViewManager? Or is that semantically different but happens to be the same value?

HeyImChris

comment created time in 3 hours

Pull request review commentmicrosoft/react-native-macos

macOS Keyboard Support

 - (BOOL)performDragOperation:(id <NSDraggingInfo>)sender } #endif // ]TODO(macOS ISS#2323203) +#pragma mark - Keyboard Events++#if TARGET_OS_OSX // TODO: add iOS keyboard event handling+- (void)keyDown:(NSEvent *)event {+  if (!self.onKeyDown) {+    [super keyDown:event];+    return;+  }++  RCTViewKeyboardEvent *keyboardEvent = [RCTViewKeyboardEvent keyDownEventWithReactTag:self.reactTag characters:event.characters modifier:event.modifierFlags];+  [_eventDispatcher sendEvent:keyboardEvent];+}+

A common pattern with keyDown:/keyUp: events is for someone to override keyDown: check the type or keys pressed or other info on the event and optionally handle it, else pass the event up the responder chain by calling super. In this react implementation it looks like the presence of an onKeyDown is what determines whether the event gets handled, so how would someone implement a "conditional" key down handler, for example one that responds to arrow keys to move an object but lets other key events pass through to the responder chain to see if someone else handles it?

It looks like the current implementation would just drop all those events on the floor?

HeyImChris

comment created time in 3 hours

issue commentmicrosoft/react-native-macos

Building/Managing NSMenu with JS

Awesome! I'll put something up and make sure to give you credit

safaiyeh

comment created time in 2 days

issue commentmicrosoft/react-native-macos

Support react-native-document-picker

Support for new platforms is a responsibility of the module, not the platform. I would suggest creating an issue on that repo or implementing it yourself.

shahthepro

comment created time in 4 days

issue commentmicrosoft/react-native-macos

Building/Managing NSMenu with JS

I don't have the bandwidth for that anytime soon, but feel free to go for it based off the code above if it helps. One thing to be careful about is that with the new RN Fabric architecture findNodeHandle is going away, so it might make more sense to build this as an actual ViewManager/Component like the Windows PR here: https://github.com/microsoft/react-native-windows/pull/2738

safaiyeh

comment created time in 7 days

issue commentmicrosoft/react-native-macos

Building/Managing NSMenu with JS

Hey @lyahdav this is amazing. I also saw ur windows one. Would you want to collaborate on making this an OSS package?

safaiyeh

comment created time in 8 days

issue commentmicrosoft/react-native-macos

Building/Managing NSMenu with JS

In case it's helpful here's my implementation of a native module for this:

  • ContextMenuNativeModule-macOS.h: https://gist.github.com/lyahdav/1afb5e98562954f971793c12b9ba5e1f
  • ContextMenuNativeModule-macOS.mm: https://gist.github.com/lyahdav/0ee567426d9001cd812b6b1dda05a700
  • ContextMenuNativeModule.tsx: https://gist.github.com/lyahdav/8c9064aadc2a5d868097ca27a1c6207b

For API look at the TS types in showNativeContextMenu in ContextMenuNativeModule.tsx.

safaiyeh

comment created time in 8 days

delete branch microsoft/react-native-macos

delete branch : publish-temp-1605816142679

delete time in 8 days

push eventmicrosoft/react-native-macos

React-Native Bot

commit sha 2794a7eccae68bbc2ae7c39557d9e22b6f557359

Applying package update to 0.63.1 ***NO_CI***

view details

push time in 8 days

create barnchmicrosoft/react-native-macos

branch : publish-temp-1605816142679

created branch time in 8 days

created tagmicrosoft/react-native-macos

tagv0.63.1

A framework for building native macOS apps with React.

created time in 8 days

create barnchmicrosoft/react-native-macos

branch : 0.63-stable

created branch time in 8 days

push eventmicrosoft/react-native-macos

Scott Kyle

commit sha 6963c6edefc7a3456b2ed9a0d83b891a0cf5eaf2

Support acceptsFirstMouse prop (#531) (#653) Presently in RN macOS, clickable views (buttons, etc.) require two clicks when that window is not in the foreground. This counter to the typical behavior on macOS where controls will default to accepting the mouse event even when in the background (and simultaneously bring to the foreground unless the command key is held).

view details

push time in 8 days

PR merged microsoft/react-native-macos

Support acceptsFirstMouse prop (#531)

Please select one of the following

  • [ ] I am removing an existing difference between facebook/react-native and microsoft/react-native-macos :thumbsup:
  • [ ] I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos :thumbsup:
  • [x] I am making a fix / change for the macOS implementation of react-native
  • [ ] I am making a change required for Microsoft usage of react-native

Summary

Presently in RN macOS, clickable views (buttons, etc.) require two clicks when that window is not in the foreground. This counter to the typical behavior on macOS where controls will default to accepting the mouse event even when in the background (and simultaneously bring to the foreground unless the command key is held).

Fixes #531

Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog -->

[macOS] [Added] - acceptsFirstMouse prop on View, Pressable, and Touchable* components

Test Plan

Confirmed in RNTester that we can successfully recognize clicks on buttons while the window is in the background, and this simultaneously brings the window to the foreground.

Microsoft Reviewers: Open in CodeFlow
+88 -3

4 comments

15 changed files

appden

pr closed time in 8 days

issue closedmicrosoft/react-native-macos

Proposal: Add acceptsFirstMouse prop to View and Touchables

Proposal: Add acceptsFirstMouse prop to View and Touchables (future: Pressable)

Presently in RN macOS, clickable views (buttons, etc.) require two clicks when that window is not in the foreground. This counter to the typical behavior on macOS where controls will default to accepting the mouse event even when in the background (and simultaneously bring to the foreground unless the command key is held).

Summary

This prop would default to false for View, but default to true on Touchable* and the future Pressable components. The NSView class has an acceptsFirstMouse: to control this behavior.

Note: In Electron, the BrowserWindow API include an acceptFirstMouse option to control this behavior for the entire window, which is better than nothing but not granular enough for a native-feeling experience on the Mac.

Motivation

This is long-standing Mac behavior, formerly described in the Apple Human Interface Guidelines (HIG) as "click-through". It should be controllable via this acceptsFirstMouse prop because there are legitimate reasons to disable it. From the old HIG:

Avoid providing click-through for an item or action whose result might be dangerous or undesirable. Specifically, avoid enabling click-through for an item that:

  • Performs a potentially harmful action that users can’t cancel (for example, the Delete button in Mail)
  • Performs an action that is difficult or impossible to cancel (such as the Send button in Mail)
  • Dismisses a dialog without telling the user what action was taken (for example, the Save button in a Save dialog that overwrites an existing file and automatically dismisses the dialog)
  • Removes the user from the current context (for example, selecting a new item in a Finder column that changes the target of the Finder window)

Open Questions

I'm not married the acceptsFirstMouse name. Electron dropped the "s", which is fine, and really anything else descriptive is fine. I don't think it should use the "click-through" terminology however, because that would be fairly confusing.

In React Native Windows, this "click-through" behavior is already present by default, thus matching the behavior of most controls on Windows. The only exception I've found on Windows are menus/toolbars, such as those in File Explorer, Office, and MS Paint. Those don't accept clicks while the window is in the background, and therefore it would reasonable to explore adding this API to React Native Windows for parity and to give developers a similar level of control.

closed time in 8 days

appden

pull request commentmicrosoft/react-native-macos

Support acceptsFirstMouse prop (#531)

:shipit:

appden

comment created time in 8 days

Pull request review commentmicrosoft/react-native-macos

Support acceptsFirstMouse prop (#531)

 import {PressabilityDebugView} from '../../Pressability/PressabilityDebug'; import usePressability from '../../Pressability/usePressability'; import {normalizeRect, type RectOrSize} from '../../StyleSheet/Rect'; import type {ColorValue} from '../../StyleSheet/StyleSheetTypes';-import type {LayoutEvent, PressEvent} from '../../Types/CoreEventTypes';+import type {LayoutEvent, MouseEvent, PressEvent} from '../../Types/CoreEventTypes'; // TODO(macOS ISS#2323203)

Rebased and fixed my silly lint error.

appden

comment created time in 8 days

Pull request review commentmicrosoft/react-native-macos

Support acceptsFirstMouse prop (#531)

 import {PressabilityDebugView} from '../../Pressability/PressabilityDebug'; import usePressability from '../../Pressability/usePressability'; import {normalizeRect, type RectOrSize} from '../../StyleSheet/Rect'; import type {ColorValue} from '../../StyleSheet/StyleSheetTypes';-import type {LayoutEvent, PressEvent} from '../../Types/CoreEventTypes';+import type {LayoutEvent, MouseEvent, PressEvent} from '../../Types/CoreEventTypes'; // TODO(macOS ISS#2323203)

It looks like the last CI error is just a lint error: it wants the items in the {} to be on their own lines. Just run yarn lint --fix.

appden

comment created time in 8 days

push eventmicrosoft/react-native-macos

Scott Kyle

commit sha 881c7d27e353c7e46c6d9ca5ae49914fe20ddc36

Use border radius when drawing focus rings (#652)

view details

push time in 8 days

PR merged microsoft/react-native-macos

Use border radius when drawing focus rings

Please select one of the following

  • [ ] I am removing an existing difference between facebook/react-native and microsoft/react-native-macos :thumbsup:
  • [ ] I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos :thumbsup:
  • [x] I am making a fix / change for the macOS implementation of react-native
  • [ ] I am making a change required for Microsoft usage of react-native

Summary

For rounded (or partially rounded) buttons, the focus ring would still draw being square. This change allows for focus rings to respect the corner radii.

Changelog

[macOS] [Fixed] - Use border radius when drawing focus rings

Test Plan

Focus rings draw circular now with border radius. Also confirmed square focus rings for views without border radius set.

Screen Shot 2020-11-15 at 6 02 54 PM

Microsoft Reviewers: Open in CodeFlow
+7 -1

4 comments

1 changed file

appden

pr closed time in 8 days

pull request commentmicrosoft/react-native-macos

Support acceptsFirstMouse prop (#531)

<!--[AutoMerge]--> Hello @alloy!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.
appden

comment created time in 8 days

pull request commentmicrosoft/react-native-macos

Support acceptsFirstMouse prop (#531)

I just merged master again and resolved new conflicts, letting CI run now.

appden

comment created time in 8 days

Pull request review commentmicrosoft/react-native-macos

Support acceptsFirstMouse prop (#531)

 - (instancetype)initWithCoder:(NSCoder *)coder   return RCTUIViewCommonInit([super initWithCoder:coder]); } +- (BOOL)acceptsFirstMouse:(NSEvent *)event+{+  if (self.acceptsFirstMouse || [super acceptsFirstMouse:event]) {+    return YES;+  }++  // If any RCTUIView view above has acceptsFirstMouse set, then return YES here.+  NSView *view = self;+  while ((view = view.superview)) {

Ok, so I take it this is resolved then?

appden

comment created time in 8 days

push eventmicrosoft/react-native-macos

Nick Gerleman

commit sha 6e788742e9c1461d853da88d4e4a68c4fc6799ee

Support focusable, Yellowbox on acceptsKeyboardFocus (#655) * Support focusable, Yellowbox on acceptsKeyboardFocus Fixes #498 This change adds support for the "focusable" property present in upstream RN, along with react-native-windows and NetUI. We need to reconcile this against the existing acceptsKeyboardFocus property. This is tricky since its usage was untyped. We follow the same strategy as react-native-windows for this. 1. Usages of acceptsKeyboardFocus will continue to work, but will yellowbox 2. Components will prefer to use focusable, and Touchables with slightly different semantics will prefer focusable semantics when present acceptsKeyboardFocus will redbox in RNW 0.64 instead of yellowbox, but this change should allow xplat code to use focusable and not be effected by that. Validated setting a view to focusable is propagated, and that acceptsKeyboardFocus is propagated with a yellowbox. * PR feedback * Explicitly false * Removed the wrong focusable...

view details

push time in 9 days

PR merged microsoft/react-native-macos

Reviewers
Support focusable, Yellowbox on acceptsKeyboardFocus

<!-- This fork of react-native provides React Native for macOS for the community. It also contains some changes that are required for usage internal to Microsoft. We are working on reducing the diff between Facebook's public version of react-native and our microsoft/react-native-macos fork. Long term, we want this fork to only contain macOS concerns and have the other iOS and Android concerns contributed upstream.

If you are making a new change then one of the following should be done:

  • Consider if it is possible to achieve the desired behavior without making a change to microsoft/react-native-macos. Often a change can be made in a layer above in facebook/react-native instead.
  • Create a corresponding PR against facebook/react-native Note: Ideally you would wait for Facebook feedback before submitting to Microsoft, since we want to ensure that this fork doesn't deviate from upstream. -->

Please select one of the following

  • [x] I am removing an existing difference between facebook/react-native and microsoft/react-native-macos :thumbsup:
  • [ ] I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos :thumbsup:
  • [x] I am making a fix / change for the macOS implementation of react-native
  • [ ] I am making a change required for Microsoft usage of react-native

Summary

Fixes #498

This change adds support for the "focusable" property present in upstream RN, along with react-native-windows and NetUI. We need to reconcile this against the existing acceptsKeyboardFocus property. This is tricky since its usage was untyped. We follow the same strategy as react-native-windows for this.

  1. Usages of acceptsKeyboardFocus will continue to work, but will yellowbox
  2. Components will prefer to use focusable, and Touchables with slightly different semantics will prefer focusable semantics when present

acceptsKeyboardFocus will redbox in RNW 0.64 instead of yellowbox, but this change should allow xplat code to use focusable and not be effected by that.

Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog -->

[macOS] [Added] - Support focusable, Yellowbox on acceptsKeyboardFocus

Test Plan

Validated setting a view to focusable is propagated, and that setting a view to acceptsKeyboardFocus works but triggers a yellowbox. More fine-grained tests for Touchable were done with the same changes in react-native-windows.

image

Microsoft Reviewers: Open in CodeFlow
+90 -43

5 comments

13 changed files

NickGerleman

pr closed time in 9 days

issue closedmicrosoft/react-native-macos

Deprecate acceptsKeyboardFocus

From Keyboarding in React Native Desktop document:

React Native core introduced focusable that does the same thing as acceptsKeyboardFocus in v0.63. Windows has added focusable and marked acceptsKeyboardFocus as deprecated in 0.63. macOS needs to do the same.

closed time in 9 days

chrisglein

pull request commentmicrosoft/react-native-macos

Support focusable, Yellowbox on acceptsKeyboardFocus

<samp> No pipelines are associated with this pull request.<br>

</samp>

NickGerleman

comment created time in 9 days

Pull request review commentmicrosoft/react-native-macos

Support focusable, Yellowbox on acceptsKeyboardFocus

 - (RCTShadowView *)shadowView // macOS properties RCT_CUSTOM_VIEW_PROPERTY(acceptsKeyboardFocus, BOOL, RCTView) {-  if ([view respondsToSelector:@selector(setAcceptsKeyboardFocus:)]) {-    view.acceptsKeyboardFocus = json ? [RCTConvert BOOL:json] : defaultView.acceptsKeyboardFocus;+  if ([view respondsToSelector:@selector(setFocusable:)]) {+    view.focusable = json ? [RCTConvert BOOL:json] : defaultView.focusable;

The native stuff is pretty much the same apart from some renaming. We map both native view properties focusable and acceptsKeyboardFocus to the same code to set focusability.

NickGerleman

comment created time in 9 days

more