Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#4,042 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
20/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript, vite
Ambito
frontend, full-stack

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
36.1k
Fork
1.1k
Merge medio
10h 41m
PR unite (30g)
363

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solidjs/solid

Tutte le issue di solidjs/solid

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.