What are the issues of using context provider at the root of the application?

If you wrap your entire Next.js app in a Context Provider in _app.js, what happens when you navigate to a page that uses server‑side rendering?

How would you fetch data inside a root context and what pitfalls might you run into on the first page load?

What effect does placing a global provider at the top have on the initial JavaScript bundle size?

You added a global auth context at the root, but after a client‑side navigation some pages still show the previous user. How would you debug and fix it?

Explain why a root context can cause unrelated components to re‑render on every state change, and suggest a way to limit that in a Next.js app.

We need per‑page theme overrides while keeping a global theme context. How would you structure the providers to avoid conflicts?

Design a strategy for using Context in a large Next.js codebase where some routes are statically generated and others are server‑side rendered, keeping performance impact low.

What are the trade‑offs of putting a provider at the root versus using route‑level providers in terms of hydration, memory usage, and code‑splitting?

If the root context holds a large mutable store, how would you prevent full‑tree re‑renders on every update in a high‑traffic site?

Your team is migrating a legacy Next.js app that uses a root‑level feature‑flag context to a micro‑frontend architecture. How would you refactor the context to support independent deployment while preserving type safety?

Discuss the long‑term maintenance risks of many teams depending on a single root context and propose governance or modularization patterns to reduce coupling.