React Server Components

[List of RSC implementations](https://twitter.com/leeerob/status/1772651496544317804)

[RSC deep dive by Dan](https://github.com/reactwg/server-components/discussions/5)

[Same site built with and without RSC](https://x.com/housecor/status/1791487717760537084)

Both server and client components render 2 things on the server:
1. HTML (yes, even client components)
2. A virtual DOM representation of the HTML (so RSC knows how to weave client components in, and how to handle client-side routing, and so client components can be "hydrated" on the client).

[My tweet with key points](https://twitter.com/housecor/status/1759576085442843122)
See the RSC project walkthrough for an example of the above: https://demystifying-rsc.vercel.app/)

## What does `use client` do?

1. It tells the bundler to output this code as a separate file with its own url so it can be loaded lazily in the browser.
2. It tells the compiler when this code is needed, it should add code to load the js file for this component.
4. It tells RSC that the Virtual DOM it generates should contain a placeholder reference to this Client Component, rather than the component's html output.
5. It still runs on the server. 'use client' does not disable SSR!

Rule: The deciding factor for what is treated as a Client Component is what is imported in the code. A client component can import and render a server component (a component that doesn't specify `use client`) as long as it doesn't do server things, and doesn't have `import server-only`.

`` in RSC causes the fallback to be immediately rendered.

Seeing hydration errors? [disable SSR for client component](https://demystifying-rsc.vercel.app/client-components/no-ssr/) or [disable SSR server side](http://localhost:3000/client-components/next-dynamic/) using Next dynamic (next/dynamic is just a composite of `React.lazy()` and ``). Or, can [useSyncExternalStore](https://twitter.com/TkDodo/status/1741068994981826947)

Devtools: https://chromewebstore.google.com/detail/rsc-devtools/jcejahepddjnppkhomnidalpnnnemomn

https://rsc-parser.vercel.app/

[3 data access approaches for RSC](https://nextjs.org/blog/security-nextjs-server-components-actions)

## Audit checklist:

[Audit](https://nextjs.org/blog/security-nextjs-server-components-actions?ref=storybookblog.ghost.io#audit)
If you're doing an audit of a Next.js App Router project here are a few things we recommend looking extra at:

- Data Access Layer. Is there an established practice for an isolated Data Access Layer? Verify that database packages and environment variables are not imported outside the Data Access Layer.
- "use client" files. Are the Component props expecting private data? Are the type signatures overly broad?
- "use server" files. Are the Action arguments validated in the action or inside the Data Access Layer? Is the user re-authorized inside the action?
- /[param]/. Folders with brackets are user input. Are params validated?
- middleware.tsx and route.tsx have a lot of power. Spend extra time auditing these using traditional techniques. Perform Penetration Testing or Vulnerability Scanning regularly or in alignment with your team's software development lifecycle.