Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de 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)?

Cerrado
  • ¿Algo no está bien?
#3,932 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
12/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
frontend, web-dev

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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!

Lenguaje dominante
TypeScript
Estrellas
36.1k
Forks
1.1k
Merge medio
9 h 56 min
PR fusionados (30 d)
336

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de solidjs/solid

Todos los issues de solidjs/solid

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.