Support for React Server Components

Describe the feature you'd like:

As a user of react 18 with NextJS (with app directory), I would like to render async server components

example:
// Page.tsx

const Page = async ({ params, searchParams }: PageProps) => {
    const asyncData = await fetchSomeDataAsynchronously()
    return (<foo {...asyncData} />
}

...
// Page.test.tsx

it('should render', () => {
    render(<Page />)
    expect(screen....).ToBe(....)
})

Extracting server page logic would be an alternative, but I think that would also significantly reduce the purpose of RTL if that were to become an encouraged architectural default.

Current progress, workarounds, and demo

You can use like this:

it('should render', async() => {
    render(<Page />);
    await waitFor(()=> {
      expect(screen....).ToBe(....)
    });
});

@prakashtiwaari

@prakashtiwaari Not quite.

It's render that's giving the issue. To provide the full error message:

'Page' cannot be used as a JSX component.
  Its return type 'Promise<Element>' is not a valid JSX element.
    
Type 'Promise<Element>' is missing the following properties from type 'ReactElement<any, any>': type, props, keyts(2786)

A friend came up with the following:

const props = {
  params: { surveyType: '123' },
  searchParams: { journeyId: '456' },
}

const Result = await Page(props)
render(Result)

I'll wait for a moderator to close this but it would be nice to have async components supported inside render

A friend came up with the following:
const props = {
  params: { surveyType: '123' },
  searchParams: { journeyId: '456' },
}

const Result = await Page(props)
render(Result)
I'll wait for a moderator to close this but it would be nice to have async components supported inside render

I like this idea personally. It should be easy enough to introspect if a component is async by determining if it returns a Promise. Then we can await the Promise internally and either return a Promise in render or poll to return synchronously.

For those that are trying to mock API responses, this seems to be working for now:

test("should do stuff", async () => {
  global.fetch = jest.fn().mockResolvedValue({
    json: jest.fn().mockResolvedValue({ login: "Gio" }),
  });
  render(await Page());
  expect(screen.getByText("Hi Gio!")).toBeInTheDocument();
});

If you don't define global.fetch, you get ReferenceError: fetch is not defined.

I would love to be able to use MSW, but that's still not working with Next's model. See: https://twitter.com/ApiMocking/status/1656249306628915208?s=20

On a side note, even if we make this work, there's the issue of Next layout composition. If I render a Page component in my test, I most likely want to render also its layout(s). I understand this is not necessarily a concern that RTL should have, but we should keep it in mind. Next could provide an API for testing that builds the whole rendering tree.

@Gpx

We could document using layouts similarly to how we already document using providers: by importing them and passing them as the wrapper option of render.

import {render} from '@testing-library/react'
import Layout from './layout'
import Page from './page'

render(<Page />, {wrapper: Layout})

@Gpx has a good point that rendering nested layouts would be more challenging. We could try to expose an abstraction, but the paths to import from would be dynamic and depend on Next patterns. If this isn't practical, we can open an issue with Next upstream and ask for an API to consume internally.

Also if we change render to be compatible with returning promises, we should probably ship a breaking change so end users are aware they may need to change their tests (especially if they're using TypeScript).

I agree we should ask Next to provide an API. I'm thinking something like this:

const RSC = routeComponent('/some/path') // This will return an RSC with all nested layouts passing the correct props
render(RSC)

// With additional props
const RSC = routeComponent('/some/path', { foo: 1 })
render(RSC)

WDYT?

As for the breaking change, won't this be a feature? I don't think anyone was relying on render breaking for async components.

I'm doing more research into RSCs using Next, and I noticed some mistaken assumptions I had:

Determining if a component uses suspense is not possible due to the halting problem as it would be valid for the component to sometimes not return a Promise, and we can't distinguish between a component not returning a Promise currently vs. ever.
The new rendering async APIs don't return Promises, they return streams. So, we don't necessarily need to make our render function async, though we may need to poll to unwrap streams synchronously.

Overall, I think supporting React server components involves figuring out the following concerns:

[react] Allow returning ReactNode from function components DefinitelyTyped/DefinitelyTyped#65135
Figuring out how we can internally render async components (may involve using a different render API, and would require using experimental/canary React right now)
Supporting bundling and routing strategies from different frameworks (we could use the adapter pattern to compose APIs from RSC frameworks such as Expose method to render whole route tree in testing vercel/next.js#50479)

@Gpx

I agree we should ask Next to provide an API. I'm thinking something like this:

const RSC = routeComponent('/some/path') // This will return an RSC with all nested layouts passing the correct props
render(RSC)

// With additional props
const RSC = routeComponent('/some/path', { foo: 1 })
render(RSC)

WDYT?

@Gpx Shouldn't that be render(<RSC />)? Also are you suggesting the URL path or filesystem path here?

The idea to render the server component as async client components seems to be the best idea I've seen so far.

I don't think it's suitable for RTL to bake Next.js' (or any other framework's) semantics into it's API. Async client components solve this by being agnostic of any framework.

I think this would retain the current RTL API with maybe the addition of a suspense wrapper - rendering nothing initially could be confusing so enforcing a fallback makes sense.

render(<Page />) // throws an error because there's no boundary (I think this would be default react behaviour)
render(<Suspense><Page /></Suspense>) // This would be ok

This workaround from #1209 (comment) still works for me with async components that have async children.

Perhaps for async FC > async FC, but not for client FC > async FC

At the moment, I have had success using this:

✅ Working:

render(await Page())

instead of this:

❌ Not working:

render(
    <Suspense>
        <Page />
    </Suspense>
)

I'm using Next 15 which comes with React 19.

At the moment, I have had success using this:

✅ Working:

render(await Page())
instead of this:

❌ Not working:

render(

)
I'm using Next 15 which comes with React 19.

This is a good workaround if the Children are sync, if the children are async you get this:

async/await is not yet supported in Client Components, only Server Components. This error is often caused by accidentally adding 'use client' to a module that was originally written for the server.
A component suspended inside an act scope, but the act call was not awaited. When testing React components that depend on asynchronous data, you must await the result:
await act(() => ...)
Unable to find an element with the text: server. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.

if you do something like this:

await act(async () => { render( await Page({ params: Promise.resolve({ something: "abc" }), }), ) await screen.findByRole("heading", { name: "Best Title", }) })

you get:

Unable to find role="heading" and name "Best Title"
Ignored nodes: comments, script, style


<body>
     <div />
  </body>

@tarunsahnan

For the complete code, check out my Gist.

@tarunsahnan thank you so much for this, it worked perfectly. I made one small update to allow the ability to pass in testing-library/react options 👍 (gist)

Good to see other people using my original code with success.

After upgrading to React 19, I had to make some changes to it. The updated version of the original gist, working with React 19, can be found here: https://gist.github.com/sroebert/a04ca6e0232a4a60bc50d7f164f101f6

@sroebert

@sroebert oh I missed you were the original author. This is a long thread 😅 we are still working on react 19 upgrade. Thank you for this, happy to know it has a solve when we migrate

Good to see other people using my original code with success.

After upgrading to React 19, I had to make some changes to it. The updated version of the original gist, working with React 19, can be found here: https://gist.github.com/sroebert/a04ca6e0232a4a60bc50d7f164f101f6

This seems to be throwing some invalid hook call warnings. Harmless but pollutes the output somewhat 🦖

Yeah tried to find a way around that, so far have not succeeded as it is baked into the React code. Guess there are very hacky ways, but those have their own drawbacks.

Progress

I had some helpful suggestions from the React team on how to start up an RSC server with full support for React RSC features (excluding Next specific features for now). I'm developing a renderServer function that simulates a React server with our existing React client.

Full integration with Next's app router depends on vercel/next.js#50479.

Workarounds

You can test most async components with React 18.3 (canary) or 19 (rc):

import { render, screen } from "@testing-library/react";
import { Suspense } from "react";
import Page from "./page";

test("Page", async () => {
render(

,
);

await screen.findBy...(...); // first assertion must await for suspense
// additional assertions may follow
});
You may want to use a custom render function to simplify test setup if your suite heavily relies on async components.

If you need other RSC (i.e. server actions) or app router (i.e. layouts) features you can use hard coding, mocks, or an e2e test framework until we figure out these issues.

server-only errors

Some React Server Components import the server-only module to prevent accidental usage in Client Components, resulting in this error:

This module cannot be imported from a Client Component module. It should only be used from a Server Component.

React Testing Library doesn't have a server yet, so it needs to render Server Components in its client for now.

If you're using Jest or Vitest, you can disable the module's error with an empty mock script named __mocks__/server-only.

With Vitest, you'll also need to manually register it:

vi.mock("server-only");
Alternatively you can mock the module in a setup or test file, for example:

jest.mock("server-only");
vi.mock("server-only", () => ({}));

TypeScript errors

Use typescript@^5.1.2 and @types/react@^18.2.8 to fix this error when rendering async components:

'...' cannot be used as a JSX component. Its return type 'Promise' is not a valid JSX element. Type 'Promise' is missing the following properties from type 'ReactElement<any, any>': type, props, key

React warnings

Newer versions of React 18.3 (canary) and 19 (rc) added warnings when rendering server components in clients:

Warning: async/await is not yet supported in Client Components, only Server Components

Warning: A component was suspended by an uncached promise. Creating promises inside a Client Component or hook is not yet supported, except via a Suspense-compatible library or framework.

However, tests following my suggestions should still work for now. I believe the warning mainly exists to prevent accidental usage of async components without a meta framework and inform users about potential instability. Remember to pin your React version in a shared package.json or lockfile though, as changes in canaries and rcs could be breaking.

Demo

I'm still using this method with the following React versions:

    "react": "19.0.0-rc-380f5d67-20241113",
    "react-dom": "19.0.0-rc-380f5d67-20241113",

It handles all cases of testing RSC, like nested async components and components using use, and I prefer to use this method rather than a custom workaround.
However, it still does not work with the React 19 release, i.e:

    "react": "19.1.0",
    "react-dom": "19.1.0",

Any insight here?

@eps1lon

At storybook, we have been investigating this problem for some time as well.
In the past we also have used the "render RSC as async client component" workaround as discussed here.
We have been discussing better ways with @eps1lon and @mattcarrollcode from the react team.

The main problem is to entangle the mix of environments:

  render(<Page />)
//^^^^^^^^^^^^^^^^ should probably run on the server 
  expect(screen....).ToBe(....)
//^^^^^^^^^^^^^^^^ is this supposed to use the DOM i.e. run in a browser?

As @sebmarkbage said earlier:

Jest has a way to test Node.js code in isolation with @jest-environment node which works fine for testing SSR output or RSC output. Jest also has a way to test client side like @jest-environment jsdom which works fine to test client-only rendering of components.
The problem is that there's no way for the same test two spawn both - and get the right export conditions set up in the module resolution. You can hack around it in various ways by setting up an environment that tries to be both but it won't test exactly the right thing and a key feature of RSC is that "server-only" and "client-only" can be mutually exclusive environments and we can have the same code run differently in each one.
To do this properly we need test runners (vitest too ideally) to adopt a way to run two environments for a single test so you can run RSC, SSR, hydrate it and assert on the result.

However, with the new vite environment API (https://vite.dev/guide/api-environment) and the release of the vite rsc plugin (https://github.com/vitejs/vite-plugin-react/tree/main/packages/plugin-rsc) we have an interesting opportunity to do exactly that, create 2 vite environments for a single vitest tests!

The test will run both environments in one (browser-like) runtime, but because of a seperate react-server environment, we can make sure that the server component tree can be serialized to react flight data with:

the correct export conditions in the module resolution (react-server)
and server specific transformations.

I am working on an experiment with that you can try out here:
https://github.com/kasperpeulen/vitest-plugin-rsc
We plan to use this in storybook for our vite specific builders and our addon-vitest that uses vitest as storybook test runner.

To use it in vitest directly, you will need to register the vitest plugin and use vitest browser mode for now:

// vitest.config.ts
import { defineConfig } from "vitest/config";
// 👇 not yet released, clone the package for now to try it out
import vitestPluginRSC from "vitest-plugin-rsc";

export default defineConfig({
  plugins: [vitestPluginRSC()],
  test: {
    browser: {
      enabled: true,
      provider: "playwright",
      instances: [{ browser: "chromium" }],
    },
    setupFiles: ["./src/vitest.setup.ts"],
  },
});

Setup the runtime:

// src/vitest.setup.ts
import { beforeAll, beforeEach } from "vitest";
import { cleanup, setupRuntime } from "vitest-plugin-rsc/testing-library";

beforeAll(() => {
  setupRuntime(); // ⬅️ spins up the RSC runtime
});

beforeEach(async () => {
  await cleanup(); // ⬅️ reset DOM between tests
});

And then you can write test like this:

import { expect, test, screen } from "vitest";
import { renderServer } from "vitest-plugin-rsc/testing-library";
import { userEvent } from "@testing-library/user-event";
import { http } from "msw";

import { Users } from "./users";
import { api } from "../lib/api";
import { getLikes } from "../lib/db";
import { msw } from "../test/msw";

test("increments likes on click", async () => {
  msw.use(
    http.get(api("/users"), () => Response.json([{ id: 5, name: "Ada" }])),
  );

  await renderServer(<Users />, { rerenderOnServerAction: true });

  expect(await getLikes(5)).toBe(0);

  await userEvent.click(await screen.findByRole("button", { name: /toggle/i }));

  await userEvent.click(await screen.findByRole("button", { name: /like/i }));

  expect(await screen.findByText("+1")).toBeVisible();
  expect(await getLikes(5)).toBe(1);
});

Vitest plugin with 2 environments

The implementation of renderServer funciton simply serializes the server component tree to react flight data with renderToReadableStream and then deserializes it back to JSX with createFromReadableStream:

import { renderToReadableStream } from "@vitejs/plugin-rsc/react/rsc";

// 👇 this is imported with a helper, to get the correct export conditions in the module resolution
const { createFromReadableStream } = await importReactClient(
  "@vitejs/plugin-rsc/react/browser"
);

// serialize
const flightStream = renderToReadableStream(<ServerComponent />);
// deserialize
const jsx = await createFromReadableStream(flightStream);

The vitest plugins spawns 2 environments.

The react-server environment is a client environment, but has the react-server condition applied, to serialize server components with right module resolution and some server specific transformation to turn client components into references.
A second client environment react_client is created that to render the client components marked with use client, deserialize the flight stream and to render the JSX to the dom.

Transformations

The transformations of the vite plugin will make sure that for a client import in the server tree like:

"use client";
import { useState } from "react";

export function Like() {
  const [count, setCount] = useState(0);
  return (
    <>
      <button onClick={() => setCount(count + 1)}>Like</button>
      <span>{count ? ` +${count} ` : ""}</span>
    </>
  );
}

Is transformed to a reference:

import { registerClientReference } from "@vitejs/plugin-rsc/vendor/react-server-dom/server";

export const Like = registerClientReference(
  /* fallback */,
  "file:///my-app/components/like.tsx",
  "Like"
);

For now I have copied over the specific transformations I needed from the RSC plugin from @hi-ogawa, as the specific stuff I needed was not included in the exports of the plugin.

Vite Environment API

I'm quite unsure about if I use the environment API correctly here. I simply made a new import helper:

import { ESModulesEvaluator, ModuleRunner } from "vite/module-runner";

const runner = new ModuleRunner(
  {
    sourcemapInterceptor: false,
    transport: {
      invoke: async (payload) => {
        const response = await fetch(
          "/@vite/invoke-react-client?" +
            new URLSearchParams({
              data: JSON.stringify(payload),
            }),
        );
        return response.json();
      },
    },
    hmr: false,
  },
  new ESModulesEvaluator(),
);

export const importReactClient = runner.import.bind(runner);

And a server handler to resolve the import with the right conditions and transformations:

const plugin = {
  configureServer(server) {
    server.middlewares.use(async (req, res, next) => {
      const url = new URL(req.url ?? "/", "https://any.local");
      if (url.pathname === "/@vite/invoke-react-client") {
        const payload = JSON.parse(url.searchParams.get("data")!);
        const result =
          await server.environments["react_client"]!.hot.handleInvoke(payload);
        res.end(JSON.stringify(result));
        return;
      }
      next();
    });
  },
};

However, hot module reload doesn't work in this way, and the plugin also seem to mess up browser module mocking somehow.
I hope to get some guidance from the vite team here.

Nextjs example

For example, I tried to make a nextjs example with module mocking:

import { describe, expect, test, vi } from "vitest";
import { renderServer } from "vitest-plugin-rsc/testing-library";
import { screen } from "@testing-library/dom";
import AuthButton from "./auth-button.tsx";
import { RequestCookiesAdapter } from "next/dist/server/web/spec-extension/adapters/request-cookies";
import { RequestCookies } from "next/dist/compiled/@edge-runtime/cookies";
import { getUser } from "../lib/session.ts";

vi.mock(import("../lib/session"), { spy: true });

vi.mock("next/headers", () => ({
  cookies: async () => RequestCookiesAdapter.seal(new RequestCookies(new Headers())),
}));

test("renders add button when logged in", async () => {
  vi.mocked(getUser).mockReturnValue("some-user");

  await renderServer(<AuthButton noteId={null}>Add</AuthButton>);

  expect(await screen.findByRole("menuitem", { name: /Add/ })).toBeVisible();
});

This works correctly the first run, but the mocks are not applied anymore in a second test run.

Especially for nextjs support, getting module mocking working seems essential to mock apis like:
cookies, headers, redirect and revalidatePath

Direction forward

Although there are some rough edges, I think this is the best way forward for unit-testing/component testing RSC's.
Running both the server and client in the same runtime, might seem weird at first, I think it is the only way to get a unit test like experience.
In a unit test, you want to be able to run any function or component in the unit test, not only specific routes.
You also want to easily mock globals, time, http, modules, fs etc.

For example, in this approach, you can mock the date in the backend and frontend with a simple line before your test:

test('allows purchases within business hours', () => {
  // set hour within business hours
  const date = new Date(2000, 1, 1, 13)
  vi.setSystemTime(date)
  await renderServer(<PurchaseItem />);
})

Or mock out http endpoints (both in the backend and client):

test("users mock", async () => {
  msw.use(http.get(api("/users"), () => Response.json([{ id: 5, name: "some user" }])));

  await renderServer(<Users />);
});

Using vitest browser mode

At this moment, I only got it working with vitest browser mode, not yet with jsdom.
It might seem useful to run it in jsdom, as RSC often run in node as well.
Personally, I think that is very useful to get visual feedback of your react components in vitest or storybook.

Also it is easier to mock our node correctly, than mock out the browser correctly.

Especially, because in modern code people often use web based API's in the RSC components such as:
fetch, Headers, Request, Response, crypto, TextEncoder, TextDecoder, URL, Blob, File, FormData, atob, btoa, ReadableStream,

The filesystem is easily mocked out with an in-memory file system:
https://vitest.dev/guide/mocking.html#file-system
Which is in general a good practice; to isolate your unit tests from IO.

And even for databases there are many browser friendly in-memory implementations:
https://github.com/morintd/prismock
https://github.com/oguimbal/pg-mem

I remember 15 years ago in asp.net webforms where code was difficult to test. This reminds me of that. But now it's 2025, and I've spent 2 hours on this. ... and of course the "solution" doesn't work.

I built nextcov to solve this exact problem. It uses V8 coverage via CDP instead of Istanbul instrumentation, so it works with SWC/Next.js 15 server components without Babel. Collects both client and server coverage from Playwright E2E tests and merges with Vitest unit coverage. Check it out: https://github.com/stevez/nextcov

docs: sharpen README pitch and add full-loop example

This is a hacky function to test async server components by awaiting Suspense components. You can call it like this:

import { test } from "vitest";

test("Async Component Render", async ({ expect }) => {
  const page = Page() // or <Page /> or any other async function;
  const { getByTestId, container } = await asyncRender(page);
  expect(getByTestId("something-to-test")).toBeDefined()
});

The gist of the program is here. The procedure is to:

stream the component to a string using the renderToPipeableStream Server API service compatible with React 19.
and render that string dangerously to HTML.

import { pipe } from "fp-ts/lib/function.js" // or from any other piping mechanism;

export const asyncRender = async (component: Promise<React.ReactElement>) =>
  pipe(component, streamComponentToString, renderStringToHTML);

Notes:

Using Vitest for testing and works in Next.JS with Server Actions and cacheComponents enabled.
Hacky comes from the fact that I'm going back and forth between html to string to html. This is because I'm streaming the async server component to a string. I'm sure there is a better way to accomplish this.
This is awaiting all Suspense components. I'm pretty sure using renderToPipeableStream is the only way to do so according to the React docs. Awaiting all Suspense components could hang so there is an optional timeout of 10000ms baked into
the streamComponentToString function.
As a reminder, this is just rendering the streamed text on the server. Any testing of interactivity is impossible. Test client components directly from the client. This is just to be used if promised content indeed lands on the page.

Full code:

import React from "react";
import { pipe } from "fp-ts/lib/function.js";
import { renderToPipeableStream } from "react-dom/server";
import { Writable } from "node:stream";
import { render } from "@testing-library/react";

export function streamComponentToString(
  component: Promise<React.ReactElement>,
) {
  return new Promise<string>((resolve, reject) => {
    let htmlBuffer = "";

    const writableStream = new Writable({
      write(chunk, encoding, callback) {
        htmlBuffer += chunk.toString();
        callback();
      },
    });

    const { pipe, abort } = renderToPipeableStream(component, {
      onAllReady() {
        try {
          pipe(writableStream);
        } catch (error) {
          reject(error);
        }
      },
      onShellError(error) {
        reject(error);
      },
      onError(error) {
        console.error("React rendering error captured:", error);
      },
    });

    writableStream.on("finish", () => {
      resolve(htmlBuffer);
    });

    writableStream.on("error", (error) => {
      reject(error);
    });

    // Optional: Setup a fail-safe timeout to abort hanging requests
    const TIMEOUT_MS = 10000;
    setTimeout(() => {
      abort();
    }, TIMEOUT_MS);
  });
}

export async function renderStringToHTML(htmlPromise: Promise<string>) {
  const html = await htmlPromise;
  return render(<div data-testid="test-wrapper" dangerouslySetInnerHTML={{ __html: html }} />);
}

export const asyncRender = async (component: Promise<React.ReactElement>) =>
  pipe(component, streamComponentToString, renderStringToHTML);

If this helps anyone, I can make a more polished final form of the function.

Navigation Menu

Repository navigation

Support for React Server Components #1209

Describe the feature you'd like:

Current progress, workarounds, and demo

137 remaining items

Progress

Workarounds

`server-only` errors

TypeScript errors

React warnings

Demo

Vitest plugin with 2 environments

Transformations

Vite Environment API

Nextjs example

Direction forward

Using vitest browser mode

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support for React Server Components #1209

Description

Describe the feature you'd like:

Current progress, workarounds, and demo

Activity

prakashtiwaari commented on May 11, 2023

remy90 commented on May 11, 2023

remy90 commented on May 11, 2023

eps1lon commented on May 11, 2023

nickserv commented on May 13, 2023

Gpx commented on May 14, 2023

nickserv commented on May 15, 2023

Gpx commented on May 15, 2023

nickserv commented on May 15, 2023

nickserv commented on May 15, 2023

tom-sherman commented on May 15, 2023

nickserv commented on May 16, 2023

tom-sherman commented on May 16, 2023

nickserv commented on May 16, 2023

tom-sherman commented on May 16, 2023

137 remaining items

baldwinn-anz commented on Mar 7, 2025

nascjoao commented on Mar 18, 2025

DanielHoernerNuernberger commented on Apr 17, 2025

JasonMore commented on Apr 25, 2025

sroebert commented on Apr 26, 2025

JasonMore commented on Apr 26, 2025

f1yingbanana commented on May 29, 2025

sroebert commented on May 29, 2025

aurorascharff commented on Jul 18, 2025

Progress

Workarounds

server-only errors

TypeScript errors

React warnings

Demo

kasperpeulen commented on Jul 26, 2025

Vitest plugin with 2 environments

Transformations

Vite Environment API

Nextjs example

Direction forward

Using vitest browser mode

kudorgyozo commented on Oct 30, 2025

stevez commented on Dec 9, 2025

sbaruffaldi commented on Jul 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`server-only` errors