Hacktoberfest 2026：维护者为十月标记出来的 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 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
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
平均合并
11 小时 32 分钟
30 天内合并 PR
356

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

solidjs/solid 的其他 Issue

查看 solidjs/solid 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。