Skip to content

fix(item-sliding, segment-button): read props after frameworks assign them - #31391

Merged
ShaneK merged 1 commit into
mainfrom
FW-7704
Aug 20, 2026
Merged

fix(item-sliding, segment-button): read props after frameworks assign them#31391
ShaneK merged 1 commit into
mainfrom
FW-7704

Conversation

@ShaneK

@ShaneK ShaneK commented Aug 20, 2026

Copy link
Copy Markdown
Member

Issue number: resolves #31388


What is the current behavior?

Currently, ion-item-sliding reads side off each ion-item-options in connectedCallback. It only waits for the option first if the element has a componentOnReady method, and the custom elements build doesn't add one, so it reads straight away and every option comes back as the default end. In v9 React that means side="start" options can't be swiped open.

There's the same problem in ion-segment-button, where the check that stops a button tied to an ion-segment-content from being disabled also runs in connectedCallback, before contentId or disabled exist.

Both come from @ionic/react v9 going through @lit/react, which assigns element props in a useLayoutEffect after React commits the DOM.

What is the new behavior?

Now updateOptions waits for every ion-item-options through the componentOnReady helper before reading side. The helper waits a frame in the custom elements build, which is after the props land, and is unchanged in the lazy build. That also drops the repo's only eslint-disable custom-rules/no-component-on-ready-method, since bypassing the helper was the bug.

The ion-segment-button check moved to componentWillLoad, and it now also requires the parent segment to be enabled. A disabled ion-segment pushes disabled onto its buttons through updateState, which is why the check used to run first, and without the new condition the fix force-enables every button inside <ion-segment disabled>.

Does this introduce a breaking change?

  • Yes
  • No

Other information

I swept every core component with a connectedCallback for this pattern and only these two break, the rest self-heal through a @Watch or an existing await. Only ion-radio-group drifts, cosmetically, and I left it alone.

The real fix isn't in core. If @stencil/react-output-target passed serializable props through React.createElement the way the v8 wrapper did, they'd be set before insertion and none of this would reach connectedCallback late. Could be worth trying to fix there for later.

Current Dev Build

9.0.1-dev.11787248963.10a00c73

@ShaneK
ShaneK requested a review from a team as a code owner August 20, 2026 18:01
@ShaneK
ShaneK requested a review from gnbm August 20, 2026 18:01
@vercel

vercel Bot commented Aug 20, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
ionic-framework Ready Ready Preview Aug 20, 2026 6:02pm

Request Review

@github-actions github-actions Bot added the package: core @ionic/core package label Aug 20, 2026

@thetaPC thetaPC left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ShaneK
ShaneK added this pull request to the merge queue Aug 20, 2026
Merged via the queue into main with commit 7956b97 Aug 20, 2026
68 checks passed
@ShaneK
ShaneK deleted the FW-7704 branch August 20, 2026 23:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

package: core @ionic/core package

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: ion-item-sliding reads option side before frameworks assign it, start options broken or open from the wrong side (v9 React)

2 participants