Adds option to allow ViewManagers to capture pointer

[rozele]

trafficstars

Adds property to ReactPointerEventArgs to allow view managers to capture the pointer while still allowing RN to emit events to JS. XAML only allows capturing the pointer on PointerPressed, so this would allow, for example, a view manager that supports custom native drag behaviors that have a threshold for action (and when that threshold is not exceeded, the gesture is handled by RN).

Microsoft Reviewers: Open in CodeFlow

[rozele]

We use this in our app for a view that responds implements native dragging that goes outside the bounds of the view. We need to capture the pointer so it continues to receive PointerMoved events after the pointer has left the bounds of the view, but we also only trigger the drag after a certain move threshold has been reached - otherwise, the gesture is treated as a "regular" RN click.

[chrisglein]

@rozele We're looking to unstick this PR that's been open for more than a year now. How does it resonate for you now? Does it still feel like the right change? Have we thought through the alignment with native expectations around Handled and such? Looking for your take and/or a smidge more detail so we know how to take this one.

[rozele]

@chrisglein - we already support working around Handled events, specifically to make selectable text pressable. This change is slightly different. The implication isn't that we necessarily want to workaround more Handled events, but rather to allow custom native components to capture the pointer. The idea is that a custom component would only set the AllowUncaptured flag if it wanted to capture the pointer while also allowing React gesture events to flow. To me, this is pretty low risk, I think the hang up was just on what to call the property. Handled doesn't feel right to me, AllowUncaptured seems like the most concise way to express the semantics, a more verbose name would be AllowReactViewToCapturePointerButStillFireGestureEvents :).

This may also be a bit too product specific, but it solves a "general" problem that can't be solved without it, which is that custom React Native components have no way to capture a pointer for potential synchronous handling without impacting / preventing normal React gesture handling, it's just a question on how many apps would actually need this behavior.

[chiaramooney]

Discussed in PR Triage. With the priority to move to Fabric, we are opting not to take this change for the Paper architecture.

[rozele]

Re-opening, as it's a relatively trivial change on an experimental public interface that keeps the delta smaller in our fork of react-native-windows.

[acoates-ms]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 1 pipeline(s).