Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[feat]: slotController synchronous `hostUpdated()`

Abierto
#3,103 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
frontend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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, no requestUpdate(), 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: hostConnected clears records → next render → hostUpdated() repopulates.

What this fixes that the current PR doesn't

  • hasSlotted() and isEmpty() have the same timing gap, they also read from #slotRecords and return incorrect results before async init completes. The hostUpdated() approach fixes all three methods.
  • Eliminates the async architecture 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

Lenguaje dominante
TypeScript
Estrellas
394
Forks
107
Métricas de merge de PR
Sin PR fusionados en 30 d

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de patternfly/patternfly-elements

Todos los issues de patternfly/patternfly-elements

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.