# 1. Setup

- Next.js (App Router) with React Compiler
- layout.tsx and almost all page.tsx files are currently rendered statically
- Header + footer live in layout.tsx; both need request headers/auth info
- Example: Country selector in the footer, rendered on the server with a default country, then updated on the client after reading a cookie

# 2. Current issue
This client-side update of the component happens before hydration finishes, producing this error:

Hydration failed because the server rendered HTML didn't match the client. The tree will be regenerated on the client.

My stop-gap is a useIsMounted hook that waits for hydration before showing the component:

import { useEffect, useState } from 'react';

export function useIsMounted(): boolean {
  const [isMounted, setIsMounted] = useState(false);
  useEffect(() => { setIsMounted(true); }, []);
  return isMounted;
}

Downsides: A small pop-in and no markup for crawlers without JS.

# 3. Questions / doubts
Should layout.tsx be marked dynamic?

export const dynamic = 'force-dynamic';

The word “force” sounds like a last-resort flag, yet the build fails if header-reading code stays static.

## Effect on child pages:
If layout.tsx is dynamic, what happens to pages that could be static?

## Performance:
Does every first render now go through SSR, increasing latency and server load?

## ISR:
Could ISR cache common variants (e.g., no explicit country) so only a subset of requests hit SSR?

## Client navigation:
After the initial load, would routing to a fully static blog post still serve the prerendered result, or does the dynamic parent layout prevent that?

I would appreciate insights or real-world patterns for handling header-dependent layouts while keeping as much SSG speed as possible.