Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

React Server Components for Pages Routing

Ouverte
  • Quelque chose ne va pas ?
#443 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
react, typescript, vite
Domaine
backend, frontend

Piste de recherche

Read the Pages protocol in the React adapter and the page scanning logic in packages/void/src/pages/scan.ts, then examine how Void configures the RSC environment in packages/void/src/index.ts and the vinext-app playground's @vitejs/plugin-rsc setup. Map how loader data is transported, prefetched, cached, and prerendered before proposing an implementation. Done means an opt-in Pages flow can return React elements from loaders while preserving client routing and existing plain data behavior.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Parts of the text were generated using an LLM, but the core purpose and intent of the proposal were written by a human.

Summary

I'd like to propose opt-in React Server Components (RSC) support for Pages mode in the React adapter, built on @vitejs/plugin-rsc. Rather than an RSC-first architecture like the Next.js App Router, a page's loader would be able to return server-rendered elements, and the page component would receive them as props — a small extension of Void's existing loader → props model.

Motivation

Void is excellent, and it looks like it could become my first choice for full-stack React apps. When comparing it with the other React meta-frameworks, the most visible gap is RSC:

Framework RSC support
Next.js (App Router) Stable, RSC-first
React Router (Framework Mode) Experimental (unstable_reactRouterRSC + @vitejs/plugin-rsc)
TanStack Start Experimental, opt-in (rsc: { enabled: true } + @vitejs/plugin-rsc)
Void (Pages mode) Not supported

I understand RSC isn't central to Void's design, and I'm not suggesting that change. But an unchecked box in these comparisons makes Void look less capable than it is, even for teams that would only use RSC in a few places.

Existing options don't fully cover this:

  • Islands already avoid client JS for static parts, but island pages use full-page navigation without the Void Router. RSC would bring the same benefit (server-only rendering, heavy dependencies that never reach the browser) to regular pages, with client navigation, actions and deferred props intact.
  • The TanStack Start / React Router integrations could provide RSC, but their RSC modes aren't covered in the integration docs, and switching gives up Pages-only features such as Void-managed auth (not yet supported in framework mode) and per-page revalidate / prerender exports.

Proposal

// pages/posts/[slug].server.tsx
import { defineHandler } from 'void';
import type { InferProps } from 'void';
import { getPost, type Post } from '../../lib/posts';
import { renderMarkdown } from '../../lib/markdown'; // markdown/highlighter code stays on the server
import { LikeButton } from './_LikeButton'; // a 'use client' component

async function PostContent({ post }: { post: Post }) {
  const html = await renderMarkdown(post.body);
  return (
    <article>
      <div dangerouslySetInnerHTML={{ __html: html }} />
      <LikeButton postId={post.id} />
    </article>
  );
}

export type Props = InferProps<typeof loader>;

export const loader = defineHandler(async (c) => {
  const post = await getPost(c.req.param('slug'));
  return {
    title: post.title, // plain data, as today
    content: <PostContent post={post} />, // rendered as a Server Component
  };
});

// pages/posts/[slug].tsx — a regular page component, unchanged
import type { Props } from './[slug].server';

export default function PostPage({ title, content }: Props) {
  return (
    <main>
      <h1>{title}</h1>
      {content}
    </main>
  );
}

How it could work:

  • Opt-in through the React adapter, e.g. voidReact({ rsc: true }). Since .server.tsx is already accepted as a companion extension, the file extension alone shouldn't change behavior.
  • When enabled, companion server modules run in the RSC environment from @vitejs/plugin-rsc, and loader results are encoded with React's Flight protocol, so props can contain React elements. Plain data keeps working as before, and defer() could map onto Flight's native promise streaming.
  • Page components and layouts stay client components, so routing, navigation, forms and hydration work as they do today. As usual with RSC, components imported into a server module render on the server unless marked 'use client'.
  • Out of scope for a first version: 'use server' Server Functions (Void actions already cover mutations) and the Vue / Svelte / Solid adapters.

Prior art

  • React Router RSC Framework Mode lets loaders and actions return React elements that render only on the server and reach the route component through loaderData — the closest match to this proposal.
  • TanStack Start creates server components in server functions (renderServerComponent, createCompositeComponent), returns them from loaders, and reads them with Route.useLoaderData().
  • Void itself already configures the Worker environment as rsc with ssr as a child for vinext App Router projects, and the vinext-app playground depends on @vitejs/plugin-rsc. So this wouldn't start from zero on the build and deploy side; most of the work would be in the Pages protocol and the React adapter.

Open questions

  • Opt-in granularity: app-wide adapter option, per-page export, or automatic when a loader returns React elements.
  • Transport: page data is JSON today (NDJSON for deferred props); RSC props need a Flight stream, at least for the React adapter.
  • Caching: how prefetch, ISR and prerendered pages store Flight payloads.
  • Islands: whether island pages should also accept server-component props.
  • Types: InferProps should expose server-rendered values as ReactNode.

I'd be happy to help test a prototype if this direction sounds reasonable.

Langage dominant
TypeScript
Étoiles
402
Forks
32
Merge moyen
12 h 1 min
PR mergées (30 j)
80

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de voidzero-dev/void

Toutes les issues de voidzero-dev/void

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.