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

[2.0 rc.14 / next] A synchronous `prepareRequest` hook makes every hydrated server-function read refetch in the browser

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

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

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

評価

難易度
3/5
見積もり時間
半日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
javascript, typescript
領域
frontend

調査の方向性

Start in packages/web/server-functions/src/client.ts, in createRequest, where config.prepareRequest is awaited even when it returns synchronously. Then read subFetch in packages/solid/src/client/hydration.ts to see how the fetch mock is swapped and restored. Done means a synchronous prepareRequest produces zero client requests after hydration for memo and store sources, and the existing client, server and hydration test suites still pass.

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

説明

Summary

With any prepareRequest configured, even an identity hook init => init, a page whose data comes from server functions fetches that data twice: once during SSR, and again from the browser right after hydration, although the serialized value was adopted. Without the hook there is no client request.

Reproduces on 2.0.0-rc.14 and on next at 358159c6.

Reproduction
// client entry, before render
import { configureServerFunctionsClient } from "@solidjs/web/server-functions/client";
configureServerFunctionsClient({ prepareRequest: init => init });

// a page reading a "use server" function through a memo or derived store
const value = createMemo(() => readThing());
return <p>{value()}</p>;

Load the page directly (SSR, then hydrate) and watch the network:

prepareRequest SSR reads Client requests after hydration
not configured 1 0
init => init 1 1

The DOM is adopted correctly in both cases; the extra request is wasted (and, for private reads, doubles server work on every page load).

Cause

Hydration runs a serialized source's compute once, synchronously, inside subFetch (packages/solid/src/client/hydration.ts), with window.fetch swapped for a never-settling mock, then restores it. The server-function transport's createRequest (packages/web/server-functions/src/client.ts) does:

if (config.prepareRequest) {
  const prepared = await config.prepareRequest(init, { id, meta });

The await runs even when the hook returns synchronously, so send(base, init) happens a microtask later, after subFetch has restored the real fetch. The call goes to the network instead of the mock.

Fix

Await only when the hook returns a promise:

-    const prepared = await config.prepareRequest(init, { id, meta });
+    let prepared = config.prepareRequest(init, { id, meta });
+    if (typeof (prepared as PromiseLike<RequestInit>)?.then === "function") prepared = await prepared;

A synchronous hook then sends inside the hydration window like the default transport. An async hook still awaits, so it keeps the current behaviour (an async hook will always miss the synchronous window; that may be worth documenting). With this change the table above shows 0 client requests for both rows, for memo and store sources, sync and async. @solidjs/web's client, server and hydration test suites pass unchanged. I can open a PR.

(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 を短くまとめたダイジェスト。