RFC: react-native 0.63 -- Pressable

[fbartho]

react-native 0.63 is out, and one of the key changes is that RN has a new component/model for pressable type elements.

As I understand it, this API model is intended to replace all the Touchable* family of APIs -- and indeed it appears to have several high level advantages that I see directly:

• It includes onPressIn/onPressOut styling callbacks Add onPressIn and onPressOut to View #1135 -- this was a clunky issue that we had to implement when using RX in our app, so it'd be great to be able to delete that state-tracking code.
• It includes more click callbacks including onLongPress

References

• https://reactnative.dev/blog/2020/07/06/version-0.63
• https://reactnative.dev/docs/pressable

Questions

• Are we interested in exposing new components in ReactXP?
• Are we interested in proactively migrating off of Touchable for the native-common interface?
• Would we accept a poly/ponyfill-type implementation of this Component which implements all or a subset of this API so that we don't have to drop RN compatibility? -- Alternatively, would we support dropping RN compatibility?

Strategies

Prerequisite: Provide a Polyfill implementing some or all of Pressable or drop RN versions

A. Switch all use cases of Touchable to Pressable in native-common -- RX.Button could be an alias / wrapper directly for RN.Pressable?
B. Expose RX.Pressable as a free standing component? -- Keep the rest of RX's native-common using Touchable?
C. Suggestions?

[fbartho]

I think I would appreciate some input from other contributors on this one, particularly around the strategic implementation questions -- @erictraut @mikehardy -- any thoughts?

[erictraut]

Replacing the RX.Button implementation to use RN.Pressable sounds like a reasonable approach. It sounds like it maps well to the semantics of RX.Button, so I'd recommend swapping implementations rather than adding a new primitive that overlaps RX.Button's behaviors.

I don't know enough about RN.Pressable to say whether this switch can be done without a breaking change in ReactXP. Some experimentation will probably need to be done. A breaking change isn't a deal-breaker, but it would need to be handled more carefully (e.g. a major version change).

[fbartho]

Thanks for the response @erictraut -- I wasn't aware if wholesale switching RX.Button to RN.Pressable was a viable option.

We already need a breaking version update to extract the Storage extension #1053, and I want to fix the ContextTypes as well which drops older React Versions #1128, so I'm leaning towards suggesting the next release be a breaking release!

Next release milestone -> https://github.com/microsoft/reactxp/milestone/1