[feat]: slotController synchronous `hostUpdated()`
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 55/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Ruhig
- Tech-Stack
- typescript
- Bereich
- frontend
Rechercherichtung
Start by locating the slotController implementation and the SlotControllerPublicAPI declaration, then trace hostConnected, #initSlotMap, the MutationObserver, and the hasSlotted(), isEmpty(), and getSlotted() methods. Implement the synchronous lifecycle described in the issue and verify initial connection, reconnection, and child mutations produce correct slot state without an async timing gap.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Alternative approach:
synchronous hostUpdated() instead of async fallback
The current fix adds a fallback in getSlotted() to query slot elements directly when #slotRecords hasn't been populated yet. This addresses the symptom but leaves the root cause: hostConnected and #initSlotMap are async, creating a timing gap where no data source exists.
The gap also affects hasSlotted() and isEmpty(), which aren't addressed here.
Why hostConnected is async
Both hostConnected and #initSlotMap await host.updateComplete just to ensure the shadow DOM exists so they can query for elements. But Lit already provides a synchronous hook that guarantees this: hostUpdated(), which runs after every render when the DOM has been committed.
Suggested change
Make hostConnected synchronous (just sets up the MutationObserver), move record initialization to hostUpdated(), and have the MutationObserver trigger a re-render instead of calling #initSlotMap directly:
hostConnected(): void {
this.#mo.observe(this.host, { childList: true });
this.#slotRecords.clear();
}
hostUpdated(): void {
if (this.#slotRecords.size === 0) {
for (let slotName of this.#slotNames.concat(Object.values(this.#deprecations))) {
slotName ||= SlotController.default;
const slot = this.#getSlotElement(slotName);
if (slot) {
this.#slotRecords.set(slotName, new SlotRecord(slot, slotName, this.host));
}
}
if (this.#slotRecords.size > 0) {
this.host.requestUpdate();
}
}
}
The MutationObserver callback becomes:
#mo = new MutationObserver(() => this.host.requestUpdate());
And #initSlotMap can be removed entirely.
This also requires updating the SlotControllerPublicAPI declaration to match:
hostConnected?(): void;
Why this works
- First render: Records empty,
isEmpty()returns true (matches SSR server behavior).hostUpdated()populates records and calls requestUpdate(). - Second render: Records exist,
isEmpty()/getSlotted()read live DOM via SlotRecord getters, correct results.hostUpdated()sees records exist, norequestUpdate(), no infinite loop. - MutationObserver: Child changes trigger
requestUpdate()→ re-render → SlotRecord getters reflect new DOM state. No record rebuild needed since they query live DOM. - Reconnection:
hostConnectedclears records → next render →hostUpdated()repopulates.
What this fixes that the current PR doesn't
hasSlotted()andisEmpty()have the same timing gap, they also read from #slotRecords and return incorrect results before async init completes. ThehostUpdated()approach fixes all three methods.- Eliminates the
asyncarchitecture that caused the issue rather than working around it.
Trade-off
The two-render pattern on initial connection is inherent <slot> elements are created by render(), so the first render can't know about them. This was already the case with the async approach.
We can spin this off to another issue if we feel the need
Originally posted by @zeroedin in https://github.com/patternfly/patternfly-elements/issues/3093#issuecomment-4252752632
- Vorherrschende Sprache
- TypeScript
- Sterne
- 394
- Forks
- 107
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus patternfly/patternfly-elements
-
bug
patternfly/patternfly-elements#3158 · 1 zugewiesene Person ·
-
patternfly/patternfly-elements#3136 · 1 Kommentar · 1 zugewiesene Person ·
-
docs
patternfly/patternfly-elements#3131 · 1 zugewiesene Person ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 55/100
patternfly/patternfly-elements#3122 ·
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 38/100
patternfly/patternfly-elements#3118 ·
Alle Issues in patternfly/patternfly-elements
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
bcgov/bc-wallet-mobile#4761 · 1 Kommentar ·
-
external-issue to-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
-
area-deployment area-integrations triage:bot-seen
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 86/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
-
refactor
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100