macOS Keyboard Support

[HeyImChris]

Please select one of the following

• I am removing an existing difference between facebook/react-native and microsoft/react-native-macos 👍
• I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos 👍
• 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

This adds macOS keyboarding support. This was also done in a way that it can be expanded to iOS hardware keyboards with a few minor additions in some followup work.

Changelog

[macOS][Added]- macOS keyboard support

Test Plan

In the RNTester I can tab focus over to Views and Buttons and print the key being pressed for both up and down presses.

Microsoft Reviewers: Open in CodeFlow

[anandrajeswaran]

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]

Hmm good point. We could let the modules initialize this with the specific keys they want passed up and then not post events for all the other keys

[alloy]

In [React] JS this would typically be controlled by conditionally invoking Event.prototype.stopPropagation() or Event.prototype.preventDefault(), see e.g. https://reactjs.org/docs/events.html. I assume there’s precedent for this in the RN codebase, but haven’t had to implement this myself yet.

The only concern I’d have is that we can't get a synchronous response and, assuming that asynchronously responding to this event is ok, what the possible lag implications are when somebody's typing. For that reason your idea of upfront describing which keys a listener handles might make sense, but it would be a deviation from typical behaviour.

[alloy]

@NickGerleman I assume this is a similar concern on Windows, no? For reference, the doc you linked to mentions:

The properties in NativeSyntheticEvent like target, bubbles, cancelable etc., are also available for IKeyboardEvent and follow the same behaviors as other events in react-native today.

[NickGerleman]

I think @acoates-ms or @FalseLobster have context into this for Windows.

[Saadnajmi]

EDIT: I had originally come back to this thread 1 year later to say that the validKeys(Up|Down) prop is non-standard and not well documented, and a rough proposal for how to not need it by doing all the event handling in JS. Then I discovered that the original Keyboarding proposal doc has a section about this exact issue, with a similar prop key(Up|Down)Events. I think it would be best if we could align with this prop / event model: It would certainly make my job writing components with custom keyboard events in FuentUI React Native easier (That's how I came back to this PR anyway).
Another helpful PR around this prop for reference: microsoft/react-native-windows#8077 .

[NickGerleman]

For extra context, react-native-windows did this a slightly different way. There, we translate key events seen by Pressability into press events, instead of having Pressability emit key events. This matches some legacy behavior, but it also means press event shape is unexpected when press happens by keyboard activation.

If you want raw pass through, it might be simpler to just avoid passing the handlers from Pressable/Touchable to Pressability.

[NickGerleman]

Do we get state change visuals on keyboard with this? IIRC hooking into the Pressability state machine gave us those for free.

[HeyImChris]

This mimics the pattern we used for onFocus and onBlur for macOS. What do you mean by state change visuals on keyboard?

[Saadnajmi]

If I understand properly, windows treats onKeyUp as onPressIn, and onKeyDown as onPressOut. Then, any visuals that might be associated with the pressed state of a perusable also happen on key press. This sounds like a desirable behavior that I think we'd want to incorporate...
I just checked and it looks like react-native-windows is still doing the same thing, so I guess the flow problems were worth the trade off?

[alloy]

In [React] JS this would typically be controlled by conditionally invoking Event.prototype.stopPropagation() or Event.prototype.preventDefault(), see e.g. https://reactjs.org/docs/events.html. I assume there’s precedent for this in the RN codebase, but haven’t had to implement this myself yet.

The only concern I’d have is that we can't get a synchronous response and, assuming that asynchronously responding to this event is ok, what the possible lag implications are when somebody's typing. For that reason your idea of upfront describing which keys a listener handles might make sense, but it would be a deviation from typical behaviour.

[HeyImChris]

Checking in as the only failure is a known Android CI failure unrelated to this