Proposal: Mock RSC payload

[vitalets]

Scope

Adds a new behavior

Compatibility

• This is a breaking change

Feature description

While I'm closely tracking the progress of App Router support in #1644, I have a proposal for solving that from another side:

Can MSW be adopted to mock React Server Component (RSC) payload?

I know that RSC is a binary format, but looking on RSC requests in devtools I see the following:

0:["development",[["children","(main)","children","__PAGE__",["__PAGE__",{}],"$L1",[null,"$L2"]]]]
4:I["(app-pages-browser)/./app/(main)/components/Pronunciation.tsx",["app/(main)/page","static/chunks/app/(main)/page.js"],"Pronunciation"]
5:I["(app-pages-browser)/./node_modules/next/dist/client/link.js",["app/(main)/not-found","static/chunks/app/(main)/not-found.js"],""]
...

Sometimes there are full JSON stringified values, that I use in my components and that I would like to mock.

I've tried to intercept such request and make plain string replacement -> values were mocked.

I've also checked server action requests, the response is also RSC with similar structure. For example, if server action throws an error, the status code is 500 and the body is:

0:["$@1",["development",null]]
1:E{"digest":"3685764491","message":"foo","stack":"Error: foo\n    at $$ACTION_0 (webpack-internal:///(rsc)/./app/page.tsx:64:11)\n   ....

Service worker could intercept that request and return mock with status 500 and custom error message. It allows to test such scenarios in components.

There is a RSC parser that could give more details on structure and what can be mocked in RSC payload.

In terms of MSW, I think of a separate RSC namespace like existing http and graphql. Pseudocode:

import { rsc, HttpResponse } from 'msw'
 
export const handlers = [
  rsc.post(
    '/pets',
    ({ request, params, cookies }) => {
      return HttpResponse.rsc(...)
    }
  )
];

What do you think?

[kettanaito]

Hi, @vitalets. Thanks for raising this.

RSC still use regular HTTP to send their payloads. There's nothing needed on MSW's side for you to intercept and mock RSC payloads! Intercept the request and mock the response (the payload). See how React encodes the payload to produce the same values for your app to decode properly.

Here's an extremely crude representation of what I mean:

http.get('/path', () => {
  return HttpResponse.text(decodePayload(payload))
})

[vitalets]

Instead, you intercept the server-side requests as usual, granted they are actually performed.

Agree, that's the ideal solution. I thought of RSC mocking as a fallback, when remote server interception is not applicable for some reason.

[kettanaito]

I believe that kind of fallback exposes your test setup to an excessive amount of implementation details behind RSC. I see no reasons why remote interception wouldn't be available, it's not that special from a regular setupServer.

I had some time to work on setupRemoteServer, and it looks good. I'd love to ship it this year.

[vitalets]

I think there could be situations in e2e area, where setupRemoteServer will be tricky / impossible:

1. concurrency handling - may require support on the framework side (what is discussed in feat: support cross-process interception via setupRemoteServer #1617)
2. pre-prod environments - for example, we have a pre-prod environment, where we run subset of e2e tests, and we are not allowed to inject any non-prod dependencies, because the code must be shipped to production from the same commit.

From that perspective, mocking RSC responses is more straightforward, with test isolation out-of-box. That's why I'm advocating for that. Although RSC payload itself is a weird thing yet.

[kettanaito]

Those are valid concerns.

1. I'm experimenting with how we can resolve this. I've got to some point with AsyncLocalStorage and function call coloring, but there are still questions to solve.
2. For this case, you deploy your pre-prod with a set of request handlers baked in, leveraging something like Dynamic mock scenarios to test different behaviors against the environment. Since you are running a subset of tests, controlling what request handlers get included should be manageable.

I must admit, I don't see how these two have anything to do with RSC. Bear in mind, if you are mocking an RSC response, you are no longer drawing a boundary at the network request your app makes. Now, you are mocking the internals of your framework to make it return different components. That's extremely dangerous and can break your app.

[vitalets]

I must admit, I don't see how these two have anything to do with RSC.

Hi @kettanaito !
The main idea - if we can mock RSC payload on the browser side, we don't need to intercept requests on the server-side, so both concerns 1 and 2 are no longer relevant.
I've created a demo based on MSW + Next.js example: https://github.com/vitalets/next-mock-rsc
There are two scenarios:

1. Initial page load: here Next streams RSC layout via self.__next_f.push in script tags. I'm going to investigate it deeper, lets' proceed to the simpler case 2 for now.
2. Subsequent navigations: here it works. Next gets RSC by fetching from url like http://localhost:3000/user?_rsc=1iwkq. These requests are correctly caught by MSW worker and can be rewritten for testing needs.

In demo I've added a new page /user with server component render:

// app/user/page.tsx

export default async function User() {
  // retrieve user from third-party API
  const user = {
    firstName: 'Real',
    lastName: 'Real',
  };

  return (
    <main>
      <p id="server-side-greeting">Hello, {user.firstName}!</p>
    </main>
  )
}

On the main page I've added a link pointing to that page: <Link href="/user">User</Link>
There is a Playwright test, that opens home page, clicks the link and checks greeting:

test('mock RSC', async ({ page }) => {
  await page.goto('/');
  await page.getByRole('link').click();

  const greeting = page.locator('#server-side-greeting')
  await expect(greeting).toHaveText('Hello, Fake!')
})

Without mocks the test does not pass, because there is Hello, Real! instead of Hello, Fake!.
Then I add the following MSW handler:

  http.get('/user', async ({ request }) => {
    const response = await fetch(bypass(request));
    const { status, statusText, headers } = response;
    const text = await response.text();
    const lines = text.split('\n');
  
    // here goes RSC patching... 
    lines[lines.length - 2] = lines[lines.length - 2].replace('Real', 'Fake');

    const newText = lines.join('\n');
    return new HttpResponse(newText, { status, statusText, headers });
  }),

Now test pass and I see Hello, Fake! in the browser.
It mocked server component page without injecting code into the app.