DEV Community: Jade Chou

NextJS Codebase Analysis(3) - how's server props and static props work?

Jade Chou — Wed, 18 Mar 2026 16:01:10 +0000

As we all know, Server Components are not allowed to use hooks like useState and useEffect—but why?

🚧 Understanding the Request Flow

Let’s start from a typical page request. When a request comes in (and possibly hits the cache), it flows through several key functions:

handleResponse
doRender
renderToHTMLOrFlightImpl
generateCacheEntry

👉 generateCacheEntry is the core of Next.js caching strategy.

🔑 Key Parameters in `generateCacheEntry`

From the function signature, we can identify some critical parameters:

encodeCacheKeyParts
fn (the actual render function)

🧩 Cache Keys and Server References

Taking a deeper look at encodeCacheKeyParts, we notice something important:

It generates keys that match those in server-reference-manifest.json.

This connects directly to concepts discussed in the previous article.

Each page/component has a corresponding cache key
These keys are heavily used across Next.js internals

⚙️ The Core Execution: `generateCacheEntryImpl`

Continuing down the call stack, we reach:

generateCacheEntryImpl — where rendering actually happens

Here, we encounter a key variable:

requestPromise

💡 This is crucial:

Server Components can be async functions
requestPromise represents the execution of the component itself
Once resolved, the result is streamed to the client

⏱️ Cache Expiration Strategy

Next.js also implements a time-based cache invalidation strategy:

When cache is invoked:
- It calculates the current time
- Compares it with the expiration time defined by the developer
Based on this, it decides:

Should we reuse the cache or regenerate it?

🗂️ Cache Retrieval

Cache entries are retrieved using:

Page key
Page path (serializedCacheKey)

📌 Example

For the URL:

http://localhost:3000/blog/2

The dynamic parameter:

  {"id": 2}

This value becomes part of the cache key

🧠 So… Why No Hooks in Server Components?

Now that we understand the flow, the reason becomes clearer:

Server Components are designed to be pure, stateless, and cacheable.

Hooks like `useState` and `useEffect`:

Depend on client-side lifecycle
Require persistent state between renders

But Server Components:

Are executed once per request (or cache hit)
Produce a deterministic output
Are serialized and streamed

👉 Allowing hooks would break caching, determinism, and streaming guarantees.

✅ Key Takeaway

Server Components trade interactivity for performance and scalability.

They work because they are:

Stateless
Deterministic
Cache-friendly

And that’s exactly why hooks like useState and useEffect are not allowed.

NextJs Codebase Analysis (2) - manifests

Jade Chou — Sun, 08 Mar 2026 14:03:58 +0000

Terminology

App Router → New routing system using /app (Next.js 13+)
Pages Router → Legacy routing using /pages
SSR → Server-Side Rendering
SSG → Static Site Generation
ISR → Incremental Static Regeneration
CSR → Client-Side Rendering
RSC → React Server Components
SPA → Single Page Application

What's the function of these manifest?

Next.js manifest files are runtime metadata maps generated at build time.

They tell Next.js exactly which files, module IDs, and extra metadata belong to each page or component. This allows the runtime to quickly resolve dependencies without re-scanning the project source during execution.

More specifically, these manifests allow the server and client runtimes to locate:

Correct JS/CSS chunks
RSC (React Server Components) client references
SRI hashes
Server Action metadata
Page/component dependency mappings

In short: manifests act as lookup tables that power the Next.js runtime.

They ensure that the framework can efficiently load the correct resources for a given request.

Take app-paths-manifest.json for example.

It is typically located at:

.next/dev/server

This file maps application routes to their compiled output files, effectively describing:

Which paths exist in the application
Which compiled chunks belong to each path

So when a request arrives, Next.js doesn't need to discover routes dynamically — it simply consults this manifest.

Why do some manifests contain encryption keys?

If we inspect server-reference-manifest.json, we can see that it includes an encryptionKey field.

Let's examine a real manifest entry to better understand this.

In this example, I created a Server Action inside my DemoActionPage.

When Next.js compiles the project:

The page is registered as a node inside server-reference-manifest
Any exported server actions are recorded
Each action is assigned a stable identifier

Important: server-reference-manifest is generated by

packages\next\src\build\webpack\plugins\flight-client-entry-plugin.ts

How Server Actions are linked to the client

When the server sends HTML to the browser, Server Actions are embedded into the markup using a hidden action binding.

Each action is associated with a unique action ID, which corresponds exactly to the key stored in server-reference-manifest.json.

How Server Action encryption works

The encryption logic used for Server Actions actually comes from React itself.

You can see the implementation here:

https://github.com/facebook/react/blob/942eb80381b96f8410eab1bef1c539bed1ab0eb1/packages/react-client/src/ReactFlightReplyClient.js#L1026

Every time a Server Action is invoked from the client:

The browser sends a POST request containing the action payload.
The payload includes encrypted action metadata and bound variables.
The Next.js server validates and decrypts the payload before executing the action.

This validation happens inside:

packages\next\src\server\app-render\action-handler.ts

The server checks the request against its local manifest map, ensuring that the action ID is valid.

This mechanism prevents action tampering or unauthorized invocation.

How the encryption key protects server variables

The Next.js documentation mentions that the encryption key is used to protect closure variables from being exposed to the client.

Let's reproduce this behavior locally to better understand it.

When a user clicks the element that triggers the Server Action:

A request is sent to the Next.js server
The request payload includes multiple encrypted parameters

These parameters originate from closure variables captured by the Server Action.

The lifecycle looks like this:

Variables are generated on the server
They are encrypted before being sent to the client
The client later invokes the action
The encrypted values are sent back to the server inside the request payload

What happens on the server during execution

If we inspect the compiled server bundle, we can see that Server Actions are transformed into a function wrapper.

This wrapper contains the same encryption key used during compilation.

During execution, the runtime calls:

decryptActionBoundArgs

This function:

Uses the encryption key
Uses action_closure_bound data
Decrypts the original closure variables

After decryption, the real variable values are restored and the action is executed normally.

Because the action runs on the server, any logging will appear in the server terminal rather than the browser console.

Key takeaway

Next.js Server Action encryption exists to guarantee two things:

Action integrity — preventing clients from forging or modifying action calls
Closure protection — ensuring server-side variables captured by actions are never exposed in plaintext

NextJs Codebase Analysis (1) - render callstacks

Jade Chou — Mon, 23 Feb 2026 16:41:01 +0000

Terminology

App Router → New routing system using /app (Next.js 13+)

Pages Router → Legacy routing using /pages

SSR → Server-Side Rendering

SSG → Static Site Generation

ISR → Incremental Static Regeneration

CSR → Client-Side Rendering

RSC → React Server Components

SPA → Single Page Application

Beginning of everything: `renderImpl`

Source code path: packages/next/src/server/render.tsx
https://github.com/vercel/next.js

handleRequest
↓
handleRequestImpl
↓
handleCatchallRenderRequest
↓
render
↓
// response html according to client end's request.
async renderImpl(req, res, pathname, query = {}, parsedUrl, internalRender = false) {
  return this.pipe((ctx) => this.renderToResponse(ctx), {
    req, // request instance
    res, // response instance
    pathname, // request page path from client end, '/page/a', '/page/c', etc
    query // params in request url, '?start=2&side=10'.
  });
}
↓
renderToResponse
↓
renderToResponseImpl
↓
renderToResponseImpl
↓
const result = await this.renderPageComponent(
  {
    ...ctx,
    pathname: match.definition.pathname, // serialize current request path, and get coordinating Component,
    renderOpts: {
      ...ctx.renderOpts,
      params: match.params,
    },
  },
  bubbleNoFallback
)
↓
renderPageComponent
↓
return await this.renderToResponseWithComponents(ctx, result);
↓
renderToResponseWithComponentsImpl
↓
await components.ComponentMod.handler(handlerReq, handlerRes, {
  waitUntil: this.getWaitUntil()
});

get page component `findPageComponents`

The rendering of a NextJs Page start with a path, Let's reusing the example on NextJs Doc website for demonstration,

it might be "/page", it will trigger renderImpl to analyze its path, and find target component path in renderPageComponent, invoke the function findPageComponentsImpl at packages/next/src/server/next-server.ts

protected async renderPageComponent(
  ctx: RequestContext<ServerRequest, ServerResponse>
) {
  // omitted.........
  const { query, pathname } = ctx
  const appPaths = this.getOriginalAppPaths(pathname)
  let page = pathname
  const result = await this.findPageComponents({ // get coordinate component by current request path.
    locale: getRequestMeta(ctx.req, 'locale'),
    page,
    query,
    params: ctx.renderOpts.params || {},
    // ................
  })
  if (result) {
    return await this.renderToResponseWithComponents(ctx, result) // render component and set result on response instance.
  }
  return false
}

It will keeping invoke function loadComponentsImpl at packages/next/src/server/load-components.ts.

we can see NextJs built server-side bundles under .next, it will be files in dev/server/app that request files under /chunks/ssr(server-side-only) to consist of a intact resource.

using component to `sendRenderResult`

After found target page component, lest keeping on plumbing logic of renderToResponseWithComponents
renderToResponseWithComponents > renderToResponseWithComponentsImpl

private async renderToResponseWithComponentsImpl()
{
 // omitted.................
 // propagate the request context for dev
 setRequestMeta(request, getRequestMeta(req))
 addRequestMeta(request, 'distDir', this.distDir)
 addRequestMeta..... omitted

 // use previous required component to render result on response instance
 await components.ComponentMod.handler(handlerReq, handlerRes, {
    waitUntil: this.getWaitUntil(),
  })
}

handler is locate at packages\next\src\build\templates\app-page.ts

export async function handler(){
  const prepareResult = await routeModule.prepare(req, res, {
    srcPage,
    multiZoneDraftMode,
  })

  // omitted..............


  await handleResponse(activeSpan)
}

We can just focus on handleResponse

const handleResponse = () => {
  const cacheEntry = await routeModule.handleResponse({
    cacheKey: ssgCacheKey,
    responseGenerator: (c) =>
      responseGenerator({
        span,
        ...c,
      }),
    routeKind: RouteKind.APP_PAGE,
    prerenderManifest,
    // omitted...........
  })

  const { value: cachedData } = cacheEntry；

  // This is a request for HTML data.
  const body = cachedData.html；

  // If there's no postponed state, we should just serve the HTML. This
// should also be the case for a resume request because it's completed
// as a server render (rather than a static render).
if (!didPostpone || isMinimalMode || isRSCRequest) {
  // normally, for a PPR request, it will come to there to sendRenderResult.
  return sendRenderResult({
    req,
    res,
    generateEtags: nextConfig.generateEtags,
    poweredByHeader: nextConfig.poweredByHeader,
    result: body,
    cacheControl: cacheEntry.cacheControl,
  })
}
}

As we can see, handleResponse will require cached data from routeModule, which would be reused in subsequent sendRenderResult

Summary

We traced the Next.js render pipeline starting from the server request handler down to renderImpl. We followed how Next.js transforms an incoming HTTP request into a rendered result by resolving page components, executing the rendering logic, and finally returning HTML through sendRenderResult.

Next post we will still focus on NextJS codebase, could pay attention if interested, and please feel free to point out any errors or omissions.

DEV Community: Jade Chou

NextJS Codebase Analysis(3) - how's server props and static props work?

🚧 Understanding the Request Flow

🔑 Key Parameters in generateCacheEntry

🧩 Cache Keys and Server References

⚙️ The Core Execution: generateCacheEntryImpl

⏱️ Cache Expiration Strategy

🗂️ Cache Retrieval

📌 Example

🧠 So… Why No Hooks in Server Components?

Hooks like useState and useEffect:

But Server Components:

✅ Key Takeaway

NextJs Codebase Analysis (2) - manifests

Terminology

What's the function of these manifest?

Why do some manifests contain encryption keys?

How Server Actions are linked to the client

How Server Action encryption works

How the encryption key protects server variables

What happens on the server during execution

Key takeaway

NextJs Codebase Analysis (1) - render callstacks

Terminology

Beginning of everything: renderImpl

get page component findPageComponents

using component to sendRenderResult

Summary

🔑 Key Parameters in `generateCacheEntry`

⚙️ The Core Execution: `generateCacheEntryImpl`

Hooks like `useState` and `useEffect`:

Beginning of everything: `renderImpl`

get page component `findPageComponents`

using component to `sendRenderResult`