fix(framework): await pending language change in connectedCallback (2.23)#13801
Merged
Merged
Conversation
…st render PR #13602 made connectedCallback bail out early for language-aware components mounted while a language change was in progress. That path silently skipped onEnterDOM, _fullyConnected, and _domRefReadyPromise resolution — so consumers that register listeners or observers in onEnterDOM (e.g. the Udex Footer's ResizeHandler.register call) never saw those side effects wired up. Replace the boolean pending flag with a promise handle so connectedCallback can await it directly and then continue on the normal render path. This keeps the lifecycle invariant intact (onEnterDOM fires exactly once, after the first render) and removes the need for any deferred-lifecycle bookkeeping. Language.ts: - languageChangePending changes from boolean to Promise<void> | null. - A single startLanguageChange helper builds the promise, runs the deferred reRenderAllUI5Elements, and clears the field when done (only if a newer change hasn't replaced it). - setLanguage() and the cross-runtime attachConfigChange handler share the helper, so both paths keep the field consistent. - getLanguageChangePending() now returns the in-flight promise or null. UI5Element.ts: - connectedCallback awaits the pending promise for language-aware components, then proceeds normally. If the deferred re-render already rendered the element during the await, skip the redundant renderImmediately. - _invalidate keeps its existing guard - a non-null promise is truthy, so the boolean check still works semantically. Tests: - New LanguageAwareLifecycle test element (languageAware: true, counts hook calls). - New base/cypress/specs/LanguageAwareLifecycle.cy.tsx covering: * onEnterDOM fires exactly once after a pending language change resolves * onEnterDOM does not fire a second time on a subsequent re-render * onEnterDOM does not fire if the element is removed before rendering Verified locally: - 3/3 pass with the fix, 2/3 fail without it. - Existing DatePicker_cldr_race and i18n_texts specs still pass.
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
1 participant
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.
Summary
Backport of #13798 to the 2.23.x line, targeting the
release-2.23.3collector branch.Following the same convention as #13733 (
fix/shellbar-13729-2.23→release-2.23.1).Why
PR #13602 shipped in 2.23.0 and introduced a bug where language-aware components mounted while
setLanguage()was in flight silently skipped `onEnterDOM`, breaking any consumer that registers listeners there (e.g. UDEX Footer's `ResizeHandler.register` — reported this week).Change
Full rationale, design, and test coverage: see #13798.
Verified locally
Related