A-8 — State Across the Network Boundary

The anti-pattern is treating Server Components like you'd treat a hook — calling auth() in every Server Component that needs the session. It's wasteful. The data flows in one direction; fetch it once at the top and pass it down.

Hoisting-and-threading is the right pattern when you control the component tree and can pass the value down explicitly. It gets awkward when several Server Components at different depths all independently need the same data and threading it through every intermediate layer would mean adding a prop that has nothing to do with those layers' own concerns. That's the case React's cache() is for.

cache() — Per-Request Deduplication Without Prop Drilling

cache(), imported from react (not from next/cache), memoizes the result of a function call for the lifetime of a single server request. Call the same cached function from five different Server Components while rendering one request, and the underlying work — a database query, a fetch — runs once; every subsequent call in that same request returns the memoized result.

// lib/data/user.ts
import { cache } from 'react';
import { auth } from '@/lib/auth';
import { db } from '@/lib/db';
 
// Wrap the lookup, not the auth() call itself — cache() keys on arguments,
// so this dedupes per userId within the request
export const getUser = cache(async (userId: string) => {
  return db.users.findUnique({ where: { id: userId } });
});

// app/dashboard/layout.tsx
export default async function DashboardLayout({ children }: { children: React.ReactNode }) {
  const session = await auth();
  const user = await getUser(session.user.id); // DB hit #1
  return <div><DashboardNav user={user} />{children}</div>;
}
 
// app/dashboard/settings/page.tsx — deep in the same tree, same request
export default async function SettingsPage() {
  const session = await auth();
  const user = await getUser(session.user.id); // same request → memoized, no DB hit
  return <SettingsForm user={user} />;
}

Both call sites ask for the same userId during the same incoming request, so the second call resolves from the in-memory cache React maintains for that request's render — it never touches the database again. This is what makes it reasonable to call a data-fetching function directly from any Server Component that needs it, instead of forcing every fetch through prop-threading from a single top-level ancestor. You get the ergonomics of "just call the function where you need the data" without paying for N duplicate queries.

This is a genuinely different mechanism from use cache elsewhere in this course, and the two are easy to conflate:

Using cache() where you meant use cache (or vice versa) is a real source of confusion: cache() will not save you a database round trip on the next incoming request — it resets completely — while use cache will, but at the cost of needing explicit revalidation when the underlying data changes. Pick cache() for "multiple components in this one render need the same thing," and use cache for "this computation is expensive and safe to reuse across users/requests."

---

Context Across the RSC Boundary

React context doesn't cross the RSC boundary. A createContext() in a Server Component cannot be consumed by a Client Component — and vice versa.

The pattern for sharing state with many Client Components without deep prop drilling:

// components/providers/UserProvider.tsx
'use client';
 
import { createContext, useContext } from 'react';
 
const UserContext = createContext<User | null>(null);
 
export function UserProvider({
  user,
  children,
}: {
  user: User | null;
  children: React.ReactNode;
}) {
  return (
    <UserContext.Provider value={user}>
      {children}
    </UserContext.Provider>
  );
}
 
export function useUser() {
  const user = useContext(UserContext);
  return user;
}

// app/layout.tsx — Server Component wraps a Client Component provider
export default async function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const session = await auth();
 
  return (
    <html>
      <body>
        <UserProvider user={session?.user ?? null}>
          {children}  {/* can be Server Components — they're passed as children */}
        </UserProvider>
      </body>
    </html>
  );
}

The critical point: children passed to UserProvider can still be Server Components. The Client Component wrapper doesn't "infect" its children with client-side rendering — children props passed from a Server Component to a Client Component remain Server Components. Only components imported by Client Components become Client Components.

---

useFormStatus and useActionState — Form-Level State

For form state that's tightly coupled to a Server Action, React provides two hooks:

useFormStatus — reads the status of the nearest <form>:

'use client';
import { useFormStatus } from 'react-dom';
 
function SubmitButton() {
  const { pending } = useFormStatus();
 
  return (
    <button type="submit" disabled={pending}>
      {pending ? 'Saving...' : 'Save'}
    </button>
  );
}

useFormStatus must be inside the form — it reads the form's pending state from React's context. It can't be in the same component as the <form> tag. This is why it's typically in a separate SubmitButton component.

useActionState — manages the state returned by a Server Action:

'use client';
import { useActionState } from 'react';
import { updateProfile } from '@/actions/users';
 
export function ProfileForm({ initialData }: { initialData: User }) {
  const [state, formAction, isPending] = useActionState(updateProfile, {
    success: false,
    errors: null,
  });
 
  return (
    <form action={formAction}>
      <input name="name" defaultValue={initialData.name} />
      {state.errors?.name && <p className="error">{state.errors.name}</p>}
      {state.success && <p className="success">Saved!</p>}
      <button disabled={isPending}>Save</button>
    </form>
  );
}

useActionState is the replacement for the deprecated useFormState. The signature is identical — it's purely a rename.

---

Zustand and Global Client State

For state that's genuinely global to the client application — theme, notification count, shopping cart — a state management library like Zustand integrates cleanly with the App Router.

The key: initialise Zustand stores from server-fetched data, not from independent client fetches.

// lib/stores/cart.ts
import { create } from 'zustand';
 
interface CartState {
  items: CartItem[];
  setItems: (items: CartItem[]) => void;
  addItem: (item: CartItem) => void;
  removeItem: (id: string) => void;
}
 
export const useCartStore = create<CartState>((set) => ({
  items: [],
  setItems: (items) => set({ items }),
  addItem: (item) => set((state) => ({ items: [...state.items, item] })),
  removeItem: (id) => set((state) => ({ items: state.items.filter(i => i.id !== id) })),
}));

// components/providers/CartProvider.tsx
'use client';
 
import { useEffect } from 'react';
import { useCartStore } from '@/lib/stores/cart';
 
// Server Component fetches the cart, passes it to this provider for initialisation
export function CartProvider({
  initialItems,
  children,
}: {
  initialItems: CartItem[];
  children: React.ReactNode;
}) {
  const setItems = useCartStore(state => state.setItems);
 
  useEffect(() => {
    setItems(initialItems); // initialise from server data once
  }, []); // eslint-disable-line — intentionally run once
 
  return <>{children}</>;
}

This pattern: server fetches the authoritative cart data, passes it to the client store as initial state, client store handles subsequent optimistic updates. The cart in the Zustand store is the "fast" version; after any mutation, revalidatePath ensures the next full page navigation fetches fresh data from the server.

---

The cookies() / headers() Boundary

A Server Component can call cookies() and headers(). A Client Component cannot — it has no access to the request. This creates a real architectural constraint: personalisation data (user preferences stored in cookies, A/B test assignments in headers) must be fetched server-side and passed to the client.

// app/layout.tsx
export default async function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const cookieStore = await cookies();
  const theme = cookieStore.get('theme')?.value ?? 'light';
  const experiment = cookieStore.get('experiment-variant')?.value;
 
  return (
    <html data-theme={theme}>
      <body>
        <ThemeProvider initialTheme={theme}>
          <ExperimentProvider variant={experiment}>
            {children}
          </ExperimentProvider>
        </ThemeProvider>
      </body>
    </html>
  );
}

The Server Component reads the cookies and passes the values to Client Component providers as props. The Client Component providers make the values available via context without needing to re-read the cookies (which they can't do).

---

The Taint API — Making Accidental Leaks a Crash Instead of a Bug

Everything so far in this module has been about deliberate patterns for moving state across the boundary. This section is about the opposite failure mode: a value that was never supposed to cross the boundary at all, crossing it by accident.

The scenario is depressingly common. A Server Component fetches a full user record — including a password hash, an internal notes field, whatever — because that's what the ORM returns. A teammate, months later, spreads that object into props for a Client Component to save a few lines:

// app/profile/page.tsx (Server Component)
export default async function ProfilePage() {
  const user = await db.users.findUnique({ where: { id: session.user.id } });
  // user includes { id, name, email, passwordHash, internalNotes, ... }
 
  // 🚨 Looks harmless. Ships the password hash to the browser.
  return <ProfileCard {...user} />;
}

Nothing here throws a type error — user really does have a name and an email that ProfileCard wants, and spreading is a normal-looking shortcut. The passwordHash field rides along silently, gets serialized into the Client Component's props, and is now sitting in the page's initial HTML/JS payload, visible to anyone who opens dev tools.

React 19 ships two APIs for turning this into a hard failure instead of a silent leak: experimental_taintObjectReference and experimental_taintUniqueValue, both imported from react. (These are still prefixed experimental_ — verify the exact export names and any required Next.js config flag against your installed React/Next versions before relying on them in production; this API has been in flux.)

// lib/data/user.ts
import { cache } from 'react';
import { experimental_taintObjectReference, experimental_taintUniqueValue } from 'react';
import { db } from '@/lib/db';
 
export const getFullUser = cache(async (userId: string) => {
  const user = await db.users.findUnique({ where: { id: userId } });
 
  // Taint the whole object: if this exact reference is ever passed
  // to a Client Component, React throws instead of silently serializing it.
  experimental_taintObjectReference(
    'Do not pass the full user record to a Client Component — pick the fields you need instead.',
    user
  );
 
  // Taint a specific sensitive value: even if someone extracts just
  // this string and tries to pass it separately, React throws.
  experimental_taintUniqueValue(
    'Do not pass the password hash to a Client Component.',
    user,
    user.passwordHash
  );
 
  return user;
});

With the taint in place, the earlier mistake stops being a silent leak and becomes a thrown error at render time:

// app/profile/page.tsx
export default async function ProfilePage() {
  const user = await getFullUser(session.user.id);
 
  // 🚨 This now throws: "Do not pass the full user record to a Client Component..."
  return <ProfileCard {...user} />;
 
  // ✅ The fix: pass only the fields the Client Component actually needs
  // return <ProfileCard name={user.name} email={user.email} />;
}

experimental_taintObjectReference protects the object identity — pass that exact object (or something derived from it in a way React can still trace) into a Client Component's props or into a Server Action's serialized response, and it throws. experimental_taintUniqueValue is narrower: it protects one specific value (a string, typically) wherever it shows up, even detached from the original object — so if a developer instead writes <ClientComp passwordHash={user.passwordHash} /> without spreading the whole object, the taint on that specific string still catches it.

Neither function encrypts or removes the data — the data is still sitting in server memory exactly as before. What they add is a fail-loud guardrail: a developer who tries to move a tainted value across the RSC boundary gets an exception during development (and in production) instead of a quiet leak that only shows up when someone inspects network traffic. This is worth adding at the data-access layer for anything that's genuinely sensitive — password hashes, API keys, internal-only fields — precisely because the mistake it prevents doesn't look like a mistake at the call site.

---

Where We Go From Here

A-9 moves to the edge — feature flags, geo-routing, and the architecture of global applications that serve different content to different users at the CDN layer. With A-8's understanding of how state flows through the component tree, A-9 explains how to use Middleware and edge compute to make routing decisions before the page even renders.

---