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

[2.0 rc.14] Feature request: prerender(view), running a view's reads to preload them without creating its elements or running its effects

Abierto
  • ¿Algo no está bien?
#3,975 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
12/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, typescript
Área
frontend, performance

Línea de trabajo

The payload names no files or tests. Start with the workaround in the body, which renders the view into a detached host inside a Loading boundary, to see which reads it triggers. Then look at how hydration runs component code once to trace dependencies, since the author suggests it as a starting point. Done means a design the maintainers accept, since the runtime or compiler support needed is their call.

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

Descripción

Summary

Preloading on hover or intent usually means listing what the next view will read, which repeats its component tree. Rendering the view itself discovers its reads, but the only way to do that today is a full client render into a detached element, kept from committing by a <Loading> that never resolves. That builds every element of the view only to discard them, gives no signal when all its reads have settled, and needs owner and context plumbing by hand. A primitive that runs a view's components and reads, and nothing else, would make render-driven preloading cheap and explicit.

Today

The current way, and the undocumented behaviour it depends on, is #3974:

function preview(view: () => JSX.Element, owner: Owner | null) {
  const host = document.createElement("div");
  return runWithOwner(owner, () =>
    render(() => {
      const gate = createMemo(() => new Promise<never>(() => {}));
      return (
        <Loading fallback={null}>
          {gate()}
          {view()}
        </Loading>
      );
    }, host),
  );
}

Measured in headless Chromium under vite dev, previewing a list with one detail per row, each element's ref logging its creation: the list's read started at 0 ms and both detail reads at 103 ms, as soon as the list answered. The ul and both p elements were created (their ref callbacks ran), but the host stayed empty and no createEffect or onSettled ran. Every element of the previewed tree is built and thrown away, and nothing reports when the detail reads finished.

Proposal
const run = prerender(() => <Page />); // under the current owner and context
run.settled; // resolves when every read in the tree, including ones found as data arrived, has settled or failed
run.dispose(); // stop early; loads already started still finish
  • Runs component bodies, memos and async reads (memos, stores, projections, lazy() and lazyModule()), following the tree level by level as data arrives, as a pending boundary does.
  • Creates no elements, render effects or effects, and commits nothing.
  • Keeps its pending state out of isPending and transitions, its holds out of the hold diagnostics, and its errors away from any <Errored>; a failed read stays failed in its source, for the real view to retry.
  • Disposes itself once settled resolves.

The compiled client output creates elements in component bodies, so skipping them likely needs runtime or compiler support; how is the maintainers' call. Hydration already runs component code once to trace dependencies (with promises held), which may be a starting point.

Related: #3213 (RFC for <Activity>, keeping hidden UI and its state; this request is narrower: no DOM and nothing kept, only the reads), #1008 (<Offscreen>), #1877 (a low-level primitive to pause effects in offscreen branches), #3941 (lazyModule(), preloading code), and React's <Activity mode="hidden">, which pre-renders hidden trees to load their data and code.

(submitted by Claude Opus 5.5 on behalf of rvlzzr)

Lenguaje dominante
TypeScript
Estrellas
36.1k
Forks
1.1k
Merge medio
11 h 34 min
PR fusionados (30 d)
341

Preparar el entorno

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 solidjs/solid

Todos los issues de solidjs/solid

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.