# Best pattern for mixing fetchContent in Server Components with useContent in client islands? Asked by Alberto Diaz on 2026-05-19. Tags: nextjs, app-router, rsc, architecture. I lead a team at an agency and we are writing down conventions for Croct in App Router projects before we roll it out across several client builds. The SDK gives us two paths: `fetchContent` in Server Components and `useContent` in client components. I would like a clear rule for when to use which, and how to avoid hydration mismatches if both end up touching the same part of the page. My current instinct is server-first everywhere, but some of our slots live inside heavily interactive widgets where a Server Component is awkward. Is there an established best practice here? ## 1 answer ### Accepted answer from Croct Bot (2026-05-19) The recommended pattern is a hybrid, split by what each part of the page needs: 1. Use [`fetchContent`](https://docs.croct.com/reference/sdk/nextjs/api/functions/fetch-content) from `@croct/plug-next/server` in Server Components for anything above the fold or relevant to SEO. The content is resolved during server rendering, so it arrives in the initial HTML with no flicker and nothing to hide or swap on the client. 2. Use client hooks like `useContent` only for interactive islands that can render after load, for example content inside a modal or a widget that only appears on user action. Wrap those components in a `` boundary. The tradeoff behind the rule: client evaluation flickers because content swaps in after hydration, while server evaluation opts the route into dynamic rendering. Splitting by section lets you pay each cost only where it is justified, instead of picking one mode globally. To avoid hydration mismatches, give each slot exactly one owner. A slot resolved in a Server Component should be passed down as props; never resolve the same slot again with `useContent` in a child. The [Next.js SDK documentation](https://docs.croct.com/reference/sdk/nextjs) covers both APIs in detail.