Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[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)?

Closed
  • Is something wrong?
#3,932 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
frontend, web-dev

Research direction

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.

Written by the indexing model from the issue text.

Description

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!

Dominant language
TypeScript
Stars
36.1k
Forks
1.1k
Avg merge
11h 27m
Merged PRs (30d)
351

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from solidjs/solid

All issues in solidjs/solid

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.