SSR_BOUNDARY_WATERFALL fires on the first cold render because of lazy route chunks, and its advice points at data
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 15/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- typescript
- 領域
- frontend
調査の方向性
Start with the reproduction: run pnpm dev in the linked solid2-mail app, then request a nested route cold and warm to confirm the first-render-only warning. The payload points at fileRoutes() and its components Map in @solidjs/router/fs (dist/fs.js), where each route's lazy() import is cached, and at the SSR_BOUNDARY_WATERFALL diagnostic. The open question is which import causes the third sequential wait, and the author has not pinned it down. Done means the chunk imports start together on the server or the diagnostic stops reporting lazy-module waits as data reads.
索引モデルが issue の本文から書いたものです。
説明
Summary
On the first SSR request after the dev server starts, the root <Loading> boundary reports SSR_BOUNDARY_WATERFALL (3 sequential waits). The waits aren't data reads. They come from fileRoutes() wrapping each code-split route component in lazy(). Each nested route level has to import() its module before the router can render the next level, so the chunks load one after another.
The warning's advice ("derive both from the same inputs", "preload the dependent data or join the requests") sends you looking at queries. The app can't fix this through queries: every query is already preloaded in parallel and wrapped in its own nested <Loading>.
Reproduction
App: https://github.com/brenelz/solid2-mail (file routes: (mail) layout → [mailbox]/[threadId] page)
- Start the dev server fresh:
pnpm dev - Make the first request a nested route:
curl -s -o /dev/null http://localhost:5173/inbox/thr-oncall - Request the same URL again.
| Request | Time | Warning |
|---|---|---|
| 1st (cold) | 1.57s | Yes |
| 2nd | 0.012s | No |
| 3rd | 0.011s | No |
[SSR_BOUNDARY_WATERFALL] A <Loading> boundary took 4 render passes — 3 sequential async waits, 173ms end to end: each read could start only after the previous one answered. If a later read doesn't need the earlier answer, derive both from the same inputs so they start together; if the dependency is intrinsic, preload the dependent data or join the requests.
in <Document> › <App> › <Router> › <RouterContextObj> › <Root> › <RootComp> › <Loading>
After you edit a route or component file, the warning comes back once, because Vite invalidates the module and it has to be imported again.
Cause
@solidjs/router/fs → fileRoutes() caches one lazy() component per route src for the lifetime of the process (dist/fs.js, the components Map). On a cold server:
- The
(mail)layout chunk is imported, and the root boundary suspends. - The layout renders and the router reaches the child, so the page chunk is imported and the boundary suspends again.
- One more sequential wait. I didn't pin down which import this is.
After that the lazy components are resolved, render synchronously, and the boundary finishes in one pass.
Expected
One or more of:
- Router: on the server, start every matched route's component import together, the same way route
preloads already run for every matched level, instead of discovering them one level per render pass. - Diagnostics: recognize waits caused by
lazy()module resolution and either skip them or report them separately, with advice about code splitting or eager server imports instead of data reads.
Versions
- solid-js 2.0.0-rc.15
- @solidjs/web 2.0.0-rc.15
- @solidjs/diagnostics 2.0.0-rc.15
- @solidjs/router 2.0.0-next.39
- @solidjs/vite-plugin 3.0.0-next.50
- filesystem-routing 0.4.0
- vite 8.3.4
- macOS (Darwin 25.5.0)
- 主要言語
- TypeScript
- スター
- 36.1k
- フォーク
- 1.1k
- 平均マージ
- 11時間 37分
- マージ済み PR（30日）
- 344
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
solidjs/solid のほかの issue
-
`lazy()`: remounting an already-loaded component renders empty (or the Suspense fallback) since 1.9.14対応中かも @itisrmk が 3 日前に担当しました。 オープン1.x
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
[2.0 rc.15 + next] For row lifecycle cleanup inherits the list computation and halts on a shared-state write対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 51/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 1〜2日 初心者へのやさしさ 48/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
-
`createRoot`'s dispose function keeps `fn` alive, so `<For>`/`<Index>` rows retain removed list items対応中かも @boombang が 5 日前に担当しました。 オープン1.x
難易度 4/5 1〜2日 初心者へのやさしさ 45/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
Sequências em espanhol: «Atualizado em», a aba «Fila» e o valor 'pause' ainda saem em portuguêsオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
melgarafael/DeskcommCRM#3104 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
bug service: webapp
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
Ocelot-Social-Community/Ocelot-Social#10684 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
nicobailon/pi-subagents#2978 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
getsentry/sentry-conventions#732 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信