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

React Server Components for Pages Routing

Open
  • Is something wrong?
#443 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
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
react, typescript, vite
Domain
backend, frontend

Research direction

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.

Written by the indexing model from the issue text.

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.

Dominant language
TypeScript
Stars
402
Forks
32
Avg merge
12h 1m
Merged PRs (30d)
80

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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 voidzero-dev/void

All issues in voidzero-dev/void

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.