fix(touchable-ripple): support function children and style on native

[giaBaoJS]

Motivation

TouchableRipple documents children and style as accepting a render function that receives the pressable state, and TouchableRipple.tsx (web) implements exactly that. TouchableRipple.native.tsx does not, so the two platforms disagree:

src/components/TouchableRipple/TouchableRipple.native.tsx (before this PR)

children: React.ReactNode;
style?: StyleProp<ViewStyle>;

vs. src/components/TouchableRipple/TouchableRipple.tsx:66-72

children:
  | ((state: PressableStateCallbackType) => React.ReactNode)
  | React.ReactNode;
style?:
  | StyleProp<ViewStyle>
  | ((state: PressableStateCallbackType) => StyleProp<ViewStyle>)
  | undefined;

Measured on main today:

• function children throws React.Children.only expected to receive a single React element child., from the bare React.Children.only(children) calls at TouchableRipple.native.tsx:98 (ripple branch) and :121 (highlight-fallback branch);
• function style is passed straight into a plain array, so it is silently dropped — the rendered props.style is [false, null], with no error at all.

The divergence dates back to #3909, which reworked the web file only.

What this PR changes

TouchableRipple.native.tsx now mirrors the web contract on both of its branches. Both React.Children.only call sites are handled, since both are reachable — :98 on Android >= Lollipop, :121 everywhere else — and a fix to only one of them would just move the bug to the other platform.

One deliberate difference from a literal copy of the web file: the render-function form is used only when the corresponding prop is actually a function. Pressable derives shouldUpdatePressed from typeof children === 'function' || typeof style === 'function' (Pressable.js:224-225), so unconditionally passing a function style would make every Button, Card, List.Item, Chip, DataTable.Row, Menu.Item, IconButton, Checkbox, RadioButton, Drawer.Item and SegmentedButtons item start re-rendering on every press-in/press-out, even though none of them use the state. Keeping the static form static makes this fix inert for the common path. The web file can pass a function unconditionally because it always needs state.hovered.

React.Children.only is kept on the resolved children, matching the web file's behaviour exactly. If #5018 lands, both call sites can be dropped together in that refactor.

The one line outside TouchableRipple: BottomNavigationBar forwards TouchableRipple's style prop to a bare react-native Pressable on its non-ripple path, and RN's PressableStateCallbackType is { pressed } while the wrapper's is { pressed, hovered, focused }. It now imports the same Pressable wrapper TouchableRipple uses — which is PressableNative as any, so this is a types-only change with no runtime effect — otherwise yarn typecheck fails there.

Related issue

Fixes #4873

Related: this looks like a missed entry on the v6 React.Children checklist in #4989 — #5018 touches 30 files and none of them is TouchableRipple.

There is also #4896 from @skainguyen1412, which addresses the same report, but it targets the 5.0 branch, so main is still affected. I'm happy to close this one if that PR gets forward-ported instead; this PR additionally covers the ripple-supported branch (:98), the function style case, and the Pressable pressed-state-tracking concern above.

Test plan

yarn lint, yarn typecheck and yarn test all pass.

src/components/__tests__/TouchableRipple.test.tsx gains 8 tests, run twice via describe.each — once with TouchableRipple.supported = false (highlight fallback) and once with true (native ripple) — so both React.Children.only call sites are covered:

• supports children as a render function
• passes the pressed state to the children render function (via testOnly_pressed, so it proves the state is actually threaded, not just that a function is invoked)
• resolves style as a function
• keeps rendering element children with a style object — non-vacuity: the pre-existing path must be untouched

Counterfactual, with the source change reverted and the tests kept:

  with the highlight fallback
    ✕ supports children as a render function (7 ms)
    ✕ passes the pressed state to the children render function
    ✕ resolves style as a function (2 ms)
    ✓ keeps rendering element children with a style object (1 ms)
  with the native ripple effect
    ✕ supports children as a render function
    ✕ passes the pressed state to the children render function
    ✕ resolves style as a function
    ✓ keeps rendering element children with a style object (1 ms)

Tests:       6 failed, 7 passed, 13 total

The three failures per branch are React.Children.only expected to receive a single React element child. (thrown from :121 and :98 respectively) and toHaveStyle not finding opacity: 0.5. With the fix applied, all 13 pass.

Full suite before: 55 passed, 732 passed / 1 skipped, 169 snapshots.
Full suite after: 55 passed, 740 passed / 1 skipped, 169 snapshots.

Snapshot churn: none. All 169 snapshots pass unmodified, which is the check that matters here — TouchableRipple underpins most touchable components in the library, and the static style array it renders is byte-identical to before.

[giaBaoJS]

Thanks for the review @ziarno.

I think this one is stuck on something outside the diff. The only check that has ever run on it is Add contributor label. ci.yml has never been dispatched, so the required checks cannot go green and the PR stays at mergeable_state: blocked even with your approval.

It is not specific to this PR. Every recent outside-contributor PR I looked at shows the same single check, while #5062 ran the full set (Unit tests, Lint, Typecheck, Build package, Build docs, Build example, CodeQL). So it looks like the workflow-approval gate for outside contributors rather than anything in the branch.

Could someone with write access kick off the workflow run? The same applies to my other open PRs here: #5047, #5048, #5064, #5065, #5066. Branch is 3 commits behind main with no conflict, happy to rebase first if you would rather see CI run on a fresh base.