Support for React Server Components

[remy90]

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

[prakashtiwaari]

You can use like this:

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

[remy90]

@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)

[remy90]

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

[eps1lon]

Once TypeScript 5.1 is out (scheduled for 30th of May) we'll land DefinitelyTyped/DefinitelyTyped#65135 which fixes this issue.

[nickserv]

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.

[Gpx]

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.

[nickserv]

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).

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

---

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

[nickserv]

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

1. 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.
2. 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:

1. [react] Allow returning ReactNode from function components DefinitelyTyped/DefinitelyTyped#65135
2. 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)
3. 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)

[nickserv]

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?

[tom-sherman]

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

[nickserv]

For anyone that wants to help, I'm trying to figure out why I can't hydrate into a server rendered document, it's like it's destroying the whole document. https://gist.github.com/nickmccurdy/a5797bec9bb7e1156f814846c9bcb04b https://github.com/nickmccurdy/rsc-testing

[tom-sherman]

Why are you trying to server render? RSC doesn't rely on SSR, that's an optional optimisation step. See https://github.com/dai-shi/wakuwork for an example of this

You need to call createFromFetch/readable from the react-server-dom-webpack/client and pass that element to react Dom to render. This ofc relies on having access to a RSC stream which you can create from the same package.

[nickserv]

I'd rather not add APIs specific to bundlers, especially since Next has already moved to other bundlers and we still have others to support in the future.

[tom-sherman]

That isn't really a bundler specific API, it includes the shared pieces shared across all bundlers. Source.