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

[2.0 rc.15] Server-component sites reached in a different order on the client bind to the wrong frame

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

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
20/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript, vite
領域
frontend, full-stack

調査の方向性

Start with findBoundaryElement(id) and how it claims document sites by ordinal (id, id~2), then compare the data-fid values on solid-frame elements in the SSR output with the client mount order. Reproduce with the App and render files in the issue, using the Vite config given there. Done means the preview updates to preview updated, the documentation block stays unchanged, and no extra hydration requests are made. The proposed content-address matching is still a design question for maintainers, so confirm that approach before writing code.

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

説明

Follow-up to #3932: while testing the multi-site adoption fix from #3933 (and its tests in #3964) on rc.15, we found that updating one server-component site can change a neighbouring frame instead.

Hydration adopts document sites of the same server function by ordinal: findBoundaryElement(id) takes the first unclaimed id, id~2, … When async setup makes SSR mint the site IDs in a different order from the one the client mounts them in, a site binds another site's element. The initial DOM looks correct and there are no warnings or requests; the first update to that site's input lands in the wrong frame.

Repro
// render.tsx
import { GET } from '@solidjs/web/server-functions';

export const render = GET(async (text: string) => {
    'use server';
    return () => <p class="block">{text}</p>;
});

// App.tsx
import { dynamic } from '@solidjs/web';
import { createMemo, createSignal, Loading, Show } from 'solid-js';
import { render } from './render.tsx';

function Block(props: { text: string }) {
    const Content = dynamic(() => render(props.text));
    return <Content />;
}

function Preview() {
    const [source, setSource] = createSignal('preview original');
    return (
        <section id="preview">
            <button onClick={() => setSource('preview updated')}>Update preview</button>
            <Block text={source()} />
        </section>
    );
}

export default function App() {
    const ready = createMemo(async () => true); // stands in for async setup
    return (
        <Loading fallback="loading">
            <Show when={ready()}>
                <Preview />
            </Show>
            <section id="docs">
                <Block text="documentation" />
            </section>
        </Loading>
    );
}

Vite with solid({ ssr: true, start: true, serverFunctions: { components: true } }). Load the page and click Update preview.

SSR renders the frames in visual order, but with IDs minted in a different order:

<solid-frame data-fid="render-62d3f108~2">preview original</solid-frame>
<solid-frame data-fid="render-62d3f108">documentation</solid-frame>

Expected: the preview shows preview updated; the documentation block is unchanged.

Actual: the preview still shows preview original and the documentation block shows preview updated. The update request returns 200; no browser errors or hydration warnings.

With createMemo(() => true) (synchronous) the IDs match the mount order and it works. rc.14 binds the right element but makes the extra hydration requests from #3932.

Versions: solid-js / @solidjs/web / signals / compiler / babel-plugin 2.0.0-rc.15, @solidjs/vite-plugin 3.0.0-next.50, Vite 8.3.3. The frames client on next (367befc) is unchanged from rc.15.

Proposed fix

Match on the call's content address as well as the site ID: annotate each document frame with its existing function/input content address and have findBoundaryElement skip unclaimed candidates whose address doesn't match. The site ID stays the claim scope. We've tried this locally; it fixes the case above and keeps zero hydration requests.

Happy to submit this as a PR if the approach sounds good and that's easier.

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

環境構築

はじめの一歩

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

solidjs/solid のほかの issue

solidjs/solid の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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