Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue number: resolves #31388
What is the current behavior?
Currently,
ion-item-slidingreadssideoff eachion-item-optionsinconnectedCallback. It only waits for the option first if the element has acomponentOnReadymethod, and the custom elements build doesn't add one, so it reads straight away and every option comes back as the defaultend. In v9 React that meansside="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 anion-segment-contentfrom being disabled also runs inconnectedCallback, beforecontentIdordisabledexist.Both come from
@ionic/reactv9 going through@lit/react, which assigns element props in auseLayoutEffectafter React commits the DOM.What is the new behavior?
Now
updateOptionswaits for everyion-item-optionsthrough thecomponentOnReadyhelper before readingside. 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 onlyeslint-disable custom-rules/no-component-on-ready-method, since bypassing the helper was the bug.The
ion-segment-buttoncheck moved tocomponentWillLoad, and it now also requires the parent segment to be enabled. A disabledion-segmentpushesdisabledonto its buttons throughupdateState, 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?
Other information
I swept every core component with a
connectedCallbackfor this pattern and only these two break, the rest self-heal through a@Watchor an existingawait. Onlyion-radio-groupdrifts, cosmetically, and I left it alone.The real fix isn't in core. If
@stencil/react-output-targetpassed serializable props throughReact.createElementthe way the v8 wrapper did, they'd be set before insertion and none of this would reachconnectedCallbacklate. Could be worth trying to fix there for later.Current Dev Build