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

[2.0 rc.14] Server components: what's the intended setup for many calls of one server function on an SSR page (e.g. code highlighting in docs)?

Chiusa
  • Qualcosa non va?
#3,932 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à
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
frontend, web-dev

Direzione di ricerca

The question is whether documentBoundary in @solidjs/web/frames should adopt later calls with different arguments, as described in frames-consistency-contract.md (C1 and pin c) and 11-server-components.md. Start with the claimedBoundaries check in documentBoundary and run the repro script to count /_server requests during hydration. Done means a decision on whether this is intended, and a fix or documented pattern that stops the extra requests, which needs maintainer input first.

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

Descrizione

Hi! This might not be a bug. It may well be me (and my coding agent, who did most of the digging) misreading how server components are meant to be used. If so, a pointer to the intended pattern would be great.

What we're doing

We render docs pages with many highlighted code blocks. Highlighting (Shiki) runs on the server through one server component, and each block calls it with its own source:

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

export const render = GET(async (text: string) => {
    'use server';
    return () => <p class="block">{text}</p>; // in the real app: Shiki's HTML
});

// App.tsx
import { dynamic } from '@solidjs/web';
import { Loading } from 'solid-js';

import { render } from './render.tsx';

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

export default function App() {
    return (
        <Loading fallback="loading">
            <Block text="one" />
            <Block text="two" />
            <Block text="three" />
        </Loading>
    );
}

// vite.config.ts
export default defineConfig({
    // Without this, SSR fails with "Seroval caught an error during the parsing process" (cf. solid-vite-plugin#394).
    ssr: { noExternal: ['seroval', 'seroval-plugins'] },
    plugins: [solid({ ssr: true, start: true, serverFunctions: { components: true } })],
});

As far as I can tell this follows examples/start-ssr/src/frames/FramesApp.tsx, except that we call the same function from several places. We use GET(fn) because the design notes call it the idiom for server components; a plain module-level 'use server' function behaves the same.

What we see

All three blocks are in the SSR HTML, but hydration adopts only the first. The other two each request /_server/data/<id> and render again on the server. The final DOM is correct and nothing is logged.

Case Blocks in SSR HTML Requests during hydration
rc.13, one call site 1 0
rc.13, three call sites 3 2
rc.14, three call sites 3 2
rc.14, production build (node dist/server/node.js) 3 2
rc.14, each block in its own <Loading> 3 2
rc.14, module-level 'use server' (POST) instead of GET(fn) 3 2

On a real docs page with ten blocks, that's nine extra highlighting requests on every load.

Why I think it might be intended

The three boundaries are stamped with the same function id:

<solid-frame data-fid="render-62d3f108" style="display:contents">
<solid-frame data-fid="render-62d3f108" style="display:contents">
<solid-frame data-fid="render-62d3f108" style="display:contents">

On the client, documentBoundary in @solidjs/web/frames adopts one element per id (claimedBoundaries.has(id)), and later mounts render fresh. frames-consistency-contract.md describes this under C1 ("client.ts:documentBoundary (a second mount goes fresh)"), and its pin (c) covers "a second mount of the same function while the first adopted mounts fresh".

But 11-server-components.md says "Boot makes zero server-function requests", and that identity is the call's (function, arguments) address, "so panes over different calls are independent". From those two docs I couldn't tell whether different arguments count as a "second mount of the same function". In #3603, the t = 0 case is also described as "covered by the document".

Questions
  1. Is fresh rendering for the second and later calls of one function the expected behavior, or should calls with different arguments be adopted too?
  2. If it's expected, what setup do you recommend for this case? Some options we considered:
    • accept the extra requests
    • return the HTML as data from a plain server function, which ships it twice (markup plus serialized data)
    • batch all blocks on a page into one server component call
    • something else we're missing
Repro

The four files above, plus a script that counts /_server requests while the page hydrates:

import { chromium } from 'playwright';

const url = process.env.URL ?? 'http://localhost:3300/';
const html = await (await fetch(url)).text();
console.log('blocks in SSR HTML:', (html.match(/class="block"/g) ?? []).length);

const browser = await chromium.launch();
const page = await browser.newPage();
const requests = [];
page.on('request', (r) => r.url().includes('/_server') && requests.push(r.url()));
await page.goto(url, { waitUntil: 'load' });
await page.waitForTimeout(2000);
console.log('blocks after hydration:', await page.locator('.block').allTextContents());
console.log('server-function requests during hydration:', requests.length, requests);
await browser.close();

blocks in SSR HTML: 3
blocks after hydration: [ 'one', 'two', 'three' ]
server-function requests during hydration: 2 [
  'http://localhost:3300/_server/data/render-62d3f108?args=%5B%22two%22%5D',
  'http://localhost:3300/_server/data/render-62d3f108?args=%5B%22three%22%5D'
]

Versions: solid-js / @solidjs/web / @solidjs/signals 2.0.0-rc.14 (also rc.13), @solidjs/vite-plugin 3.0.0-next.47, Vite 8.3.3, Node 24.20.0, macOS 26.2, Chrome for Testing 153.

Possibly related: #2973 (adopted frames keyed by call address), #3889 (two mounts of one server-component result), discussion #3603 (request batching; server-component request grouping is on hold there because t = 0 is covered by the document).

Thanks!

Lingua principale
TypeScript
Stelle
36.1k
Fork
1.1k
Merge medio
11h 27m
PR unite (30g)
351

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.