Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#3,975 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
12/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
javascript, typescript
領域
frontend, performance

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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)

主要言語
TypeScript
スター
36.1k
フォーク
1.1k
平均マージ
9時間 56分
マージ済み PR（30日）
336

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

solidjs/solid のほかの issue

solidjs/solid の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。