Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[2.0 rc.15 / next] Docs: say when a ref callback runs (not yet connected), and that ref-attached native listeners run before delegated handlers

Aperta
  • Qualcosa non va?
#4,083 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
Mezza giornata
Idoneità per principianti
55/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript, typescript
Ambito
documentation, frontend

Direzione di ricerca

Start with documentation/solid-2.0/07-dom.md, then check the ref examples in MIGRATION.md and CHEATSHEET.md, and the "Root-owned event delegation" section. Run the linked repro (bun run repro) to confirm the ref timing and listener order before writing anything. Done means the docs state when a ref runs relative to connection, rewrite the autofocus example to use onSettled, and note that ref-attached native listeners run before delegated onX handlers and how that affects stopPropagation().

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

The 2.0 DOM docs (documentation/solid-2.0/07-dom.md, MIGRATION.md, CHEATSHEET.md) make ref the place for directives and for native listener options. They leave out two timing facts that the 1.x docs stated and that rc.15 still has. Both catch people who follow the 2.0 examples as written.

1. A ref runs before the element is in the document

The 1.x docs say: "The directive functions are called at render time, but are called before the element is added to the DOM." The 2.0 docs never say when a ref runs. They use ref={autofocus} and ref={[autofocus, tooltip({ content: "Save" })]} as headline examples without defining autofocus. The migration guide also says that "element-dependent work rides the apply callback or an effect".

The obvious reading does nothing:

import { onSettled } from "solid-js";

export const log: string[] = [];

// The obvious reading of `ref={autofocus}` from the 2.0 docs.
const autofocus = (el: HTMLElement) => {
  log.push(`autofocus ref: isConnected=${el.isConnected}`);
  el.focus();
};

export function App() {
  let input!: HTMLInputElement;
  onSettled(() => {
    log.push(`onSettled: input.isConnected=${input.isConnected}`);
  });
  return (
    <>
      <input id="naive" ref={autofocus} />
      <input id="other" ref={input} />
    </>
  );
}

Chrome 149, after render():

autofocus ref: isConnected=false
onSettled: input.isConnected=true
document.activeElement: #BODY

Request: state when a ref callback runs: after the element is created and its static attributes are set (#4080 covers the attributes that are not yet set), before its children are inserted, and before it is connected. Show autofocus written so that it works, for example a factory whose owned setup uses onSettled:

const autofocus = () => {
  let el: HTMLElement | undefined;
  onSettled(() => el?.focus());
  return (node: HTMLElement) => void (el = node);
};
2. Native listeners added from a ref run before delegated onX handlers

Delegated handlers run from the render root's listener. A native listener added by a ref therefore runs before every delegated handler for the same event, including a delegated handler on a descendant. Using the on helper from 07-dom.md:

const on = (type: string, handler: (e: Event) => void, options?: AddEventListenerOptions) =>
  (el: HTMLElement) => el.addEventListener(type, handler, options);

export const log: string[] = [];

export const App = () => (
  <>
    {/* a: native listener on a parent, delegated onClick on its child */}
    <div id="a" ref={on("click", () => log.push("parent: native listener"))}>
      <button id="a-btn" onClick={() => log.push("child: onClick (delegated)")}>a</button>
    </div>
    {/* b: the same parent listener calls stopPropagation() */}
    <div id="b" ref={on("click", (e) => { e.stopPropagation(); log.push("parent: native listener, stopPropagation()"); })}>
      <button id="b-btn" onClick={() => log.push("child: onClick (delegated)")}>b</button>
    </div>
    {/* c: native listener and delegated onClick on one element */}
    <button
      id="c"
      onClick={() => log.push("same element: onClick (delegated)")}
      ref={on("click", (e) => { e.stopPropagation(); log.push("same element: native listener, stopPropagation()"); })}
    >
      c
    </button>
  </>
);

Clicking #a-btn, #b-btn and #c in turn:

-- click #a-btn
parent: native listener
child: onClick (delegated)
-- click #b-btn
parent: native listener, stopPropagation()
-- click #c
same element: native listener, stopPropagation()

The parent's listener runs before the child's handler. A stopPropagation() in a native listener silences every delegated handler at or below that element, and a delegated handler cannot stop a native listener on an ancestor, because that listener has already run. The 1.x docs had a caveat about stopPropagation() with document-level delegation. Root-owned delegation in 2.0 keeps this behaviour, and the 2.0 docs now present ref={on(...)} next to onClick as the standard pattern without any caveat.

Request: add a short note under "Root-owned event delegation" or next to the on(...) example. It should say that native listeners attached with ref run before delegated handlers, and what that means for stopPropagation().

Versions
  • solid-js, @solidjs/web, @solidjs/compiler 2.0.0-rc.15; the docs as on next at eb4e019
  • Case 1: headless Chrome 149. Case 2: happy-dom 21.0.1 (the order follows from where the listeners are attached)
Context

I found these while building a headless UI library on 2.0. Its behaviours are ref factories (focus, outside-press and keyboard listeners, measuring) composed with delegated handlers on the same parts.

Runnable repro: https://gist.github.com/cevr/5d94b73bc4803f440482c266a68280d2 (bun install && bun run repro)

Filed with Claude Code on behalf of @cevr.

Lingua principale
TypeScript
Stelle
36.1k
Fork
1.1k
Merge medio
10h 41m
PR unite (30g)
363

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solidjs/solid

Tutte le issue di solidjs/solid

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.