How to Use a Component Library in Next.js App Router Without Breaking Server Components

Using a component library in Next.js App Router requires a little architectural care. The App Router encourages Server Components by default, while many UI components need client-side behavior for state, events, focus management, or browser APIs.

The goal is not to avoid Client Components completely. The goal is to put the client boundary where it belongs.

Keep pages server-first when possible

Pages and layouts are excellent places for server-side work:

• Loading content.
• Creating metadata.
• Generating structured data.
• Reading files or database records.
• Building sitemap-friendly routes.

If a page can fetch or prepare data on the server, keep that logic there. Then pass serializable props into a client component for interactive UI.

This pattern keeps SEO metadata and static content reliable while still allowing rich controls.

Move interactivity into client components

Any component that uses useState, useEffect, event handlers, browser APIs, or interactive focus behavior must be a Client Component.

That includes common UI patterns like:

• Filters.
• Search inputs.
• Tabs.
• Theme controls.
• Menus.
• Dialogs.
• Toasts.
• Interactive forms.

Place "use client" at the top of the smallest component that needs it. Avoid turning an entire page into a Client Component just because one control needs state.

Pass serializable data across the boundary

Server Components can pass data to Client Components, but that data needs to be serializable. Avoid passing functions, class instances, file handles, or rich objects that only exist on the server.

For a blog page, the server might load Markdown, format dates, and build a plain array of post objects. The client component can then filter, sort, and render those posts.

That gives you the best of both worlds:

• Server-side content and metadata.
• Client-side controls and interaction.

Watch library imports

Some component libraries separate server-safe components from client-only components. Others require specific imports for Next.js.

If a component uses browser APIs internally, import it only from Client Components. If the library provides static components that can render on the server, use them where appropriate.

The safest approach is to read the library's Next.js guidance and keep interactive UI in clearly named client wrappers.

Theme providers and App Router layouts

Theme providers are often client-side because users can switch themes interactively. But initial theme attributes may need to be applied in the server layout to avoid flashes or hydration mismatch.

Good setup usually includes:

• Server-readable default theme.
• HTML attributes or CSS variables available before hydration.
• A client provider for interactive updates.
• Stable global styles imported once.

This is especially important for component libraries with themeable surfaces and color schemes.

Boreal UI and Server Components

Boreal UI is intended to work in React and Next.js projects where server-rendered content and client interaction both matter.

For a Next.js blog, documentation page, or product site, a useful pattern is:

• Keep the route page server-rendered.
• Generate metadata and schema on the server.
• Load content on the server.
• Pass simple post or docs data into a client provider.
• Let the client provider handle filters, controls, and interactions.

This keeps the App Router architecture clean.

The rule of thumb

Use Server Components for data, content, metadata, and static layout.

Use Client Components for controls, state, events, and browser behavior.

A component library should help you respect that split instead of forcing everything into the client. When that boundary is clear, you can use rich UI components without breaking the strengths of the Next.js App Router.