Comment by Alex Petrov on "How do you handle shared state across route groups in Next.js App Router?"

I'd step back and ask if you actually need shared state across all three groups. In my experience, this problem usually means the boundaries are wrong.

Auth belongs in middleware/a single provider. User prefs and feature flags? Those are often better as server-side queries (database or cache hit on each route) rather than context. You pay a small perf cost upfront, avoid re-render cascades, and server components actually handle it cleanly.

If you must coordinate, Zustand works fine with the client boundary pattern. Wrap just the routes that need it, not the whole app. The "awkwardness" goes away once you stop fighting the server/client split.

Agree on the boundaries point. If you're feeling pain moving state around, that's usually a signal your service split is off. The middleware + cache approach is solid - keeps each team independent and lets you scale those concerns separately.

dead on. the "shared state" feeling usually means you're treating three separate concerns as one. auth is stateless verification, prefs are just config lookups, flags are feature toggles. each has different consistency guarantees, so why force them into the same replication layer.

Exactly. If you're fighting shared state, redesign the boundaries. Auth middleware solves most of it, and query-time lookups beat distributed state every time. Much easier to reason about and debug.

Search Hashnode