Shopify / Shopify/checkout-sheet-kit-react-native

AcceleratedCheckoutButtons: self-reported height is ignored (flex: 1 beats height) — touch area smaller than rendered buttons, taps on button edges are silently dropped

Open Beginner friendly
#502 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

stale
Dominant language
TypeScript
Stars
80
Forks
17
Avg merge
3h
Merged PRs (30d)
3

Description

What area is the issue related to?

Checkout Sheet Kit

What platform does the issue affect?

iOS

What version of @shopify/checkout-sheet-kit are you using?

3.8.1 · iPhone (iOS 18, physical device) · react-native 0.86.0 · Expo SDK 57

Do you have reproducible example code?
// Container without an explicit height — relies on the buttons sizing themselves:
<View style={{ minHeight: 48 }}>
  <AcceleratedCheckoutButtons
    cartId={cartId}
    wallets={[AcceleratedCheckoutWallet.applePay, AcceleratedCheckoutWallet.shopPay]}
    applePayLabel={ApplePayLabel.buy}
    onComplete={onComplete}
    onFail={onFail}
  />
</View>
Steps to Reproduce
  1. Render AcceleratedCheckoutButtons with two wallets inside a container that has no explicit height (e.g. minHeight: 48 or nothing at all).
  2. On a device, tap the top edge of the first button or the bottom edge of the second button.
  3. Nothing happens. Taps only work in a horizontal strip in the vertical middle of the button stack.

To verify where touches go, attach onTouchStart/onLayout to the container: taps on the button edges never produce a touch event in RN at all, and the container's layout height stays at the container's own height (e.g. 48) instead of growing to the reported wallet height (104 for two wallets).

Expected Behavior

The native view sizes itself to the height it reports via onSizeChange (numberOfWallets * 48 + (numberOfWallets - 1) * 8), so the touchable area matches what is drawn on screen and every tap on a visible button opens the payment sheet.

Actual Behavior

The buttons are drawn at full size but the touch area stays at the container's height. The dynamicHeight mechanism in the JS wrapper is a no-op:

src/components/AcceleratedCheckoutButtons.tsx renders the native view with

const defaultStyles = {flex: 1};
// ...
style={{...defaultStyles, height: dynamicHeight}}

flex: 1 sets flexBasis: 0, and in Yoga a non-auto flexBasis takes precedence over height on the main axis. So the height reported by the native side (resizeWallets()onSizeChangesetDynamicHeight) is applied to the style but never affects layout. The native view stays as tall as its parent makes it; the SwiftUI hosting view (pinned to the RCT view's bounds) centers its 104 pt content in that smaller frame and draws beyond the frame — visible, but outside iOS hit-testing bounds. Result: only the middle ~48 pt strip of the button stack is tappable, which surfaces to users as "the Apple Pay button only reacts every few taps".

Possible fix: drop flex: 1 from defaultStyles (or use flexBasis: 'auto') so height: dynamicHeight actually applies.

Workaround for anyone hitting this: give the container an explicit height matching the wallet stack, e.g. height: 104 for two wallets (2×48 + 8 gap).

Storefront domain

alb-filter.myshopify.com

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in src/components/AcceleratedCheckoutButtons.tsx and trace the onSizeChange → setDynamicHeight flow from the native view. Verify how the default flex style affects the reported height, then confirm that the two-wallet reproduction grows to 104 points and that taps on the visible button edges reach the payment sheet.

Written by the indexing model from the issue text.

Assessment

Tech stack
ios, react-native, typescript
Domain
mobile
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
84/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.