feat(Pressable): add support for PlatformColor and alpha#56395
feat(Pressable): add support for PlatformColor and alpha#56395adrcotfas wants to merge 1 commit intofacebook:mainfrom
Conversation
|
Hi @adrcotfas! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
a6fdea3 to
9b4bdac
Compare
Summary:
android_rippleonPressable(andTouchableNativeFeedback.Ripple()) onlyaccepted numeric (pre-processed ARGB int) colors. Passing a
PlatformColorwould throw an invariant in JS, making it impossible to use theme-aware colors for the ripple effect.
This PR fixes two separate guards that blocked
PlatformColor:useAndroidRippleForView.js): removed theinvariantthatrejected non-numeric processed colors.
NativeDrawable.h): switched fromhasType<int32_t>()to theshared
fromRawValuepipeline (same path used by every other color prop),which resolves
PlatformColorobjects via JNI.A new
alpha: number(0–1) field is also added so users can apply opacity toa
PlatformColorwhose value is fully opaque and can't have alpha embedded atthe JS level.
Unresolvable
PlatformColorresources are handled gracefully: on New Arch,C++ detects
UndefinedColorand omits thecolorkey so Kotlin falls back tocolorControlHighlight; on Old Arch,ReactDrawableHelpercatches theJSApplicationCausedNativeExceptionand falls back tocolorControlHighlightinstead of crashing.
Changelog:
[ANDROID] [ADDED] -
android_ripplenow acceptsPlatformColorfortheme-aware ripple colors, and a new
alpha(0–1) parameter for controllingripple opacity independently of the color value.
Test Plan:
Automated:
PlatformColor + alphato use?attr/colorAccent(matching the RNTester example).
should not crash with an unresolvable PlatformColorverifying the component renders at the JS level without throwing.
Manual (RNTester → Pressable → "Pressable with PlatformColor ripple and alpha"):
PlatformColor('?attr/colorAccent'), no alpha→ full-opacity accent ripplePlatformColor('?attr/colorAccent'), alpha=0.3→ 30% opacity accent ripple#FF0000, no alpha→ full red ripple (regression check)#FF0000, alpha=0.5→ 50% opacity red rippleinvalidation works)
?attr/doesNotExist) → nocrash, ripple falls back to default
colorControlHighlightgreyPressable_PlatformColor_alpha.webm