Server and Client Components

The page stays on the server: it queries the course and renders the heading, description and outline as HTML with no JavaScript attached. Two small client components handle the interactive parts — one for the expandable module list, one for the completion button that touches local storage.

The important detail is that the module list's content does not have to be a client component. The client wrapper owns the open and closed state and renders whatever children it is given, so the server-rendered lesson markup passes straight through. That keeps the formatting, the links and any helper functions out of the browser bundle.

A tempting alternative is to mark the whole page "use client" and use one piece of state for everything. It is fewer files, and it sends the entire page's code plus the database helper's imports to the browser, and forces the course data to be fetched through an API route instead of directly.

The completion button is separate from the module list on purpose. They share no state, so combining them would put both into one bundle chunk and couple two unrelated pieces of behaviour.

// app/courses/[slug]/page.tsx — server component
import { getCourseBySlug } from "@/data/courses";
import { ExpandableSection } from "./ExpandableSection";
import { CompletionButton } from "./CompletionButton";

export default async function CoursePage({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;
  const course = await getCourseBySlug(slug);

  return (
    <article>
      <h1>{course.title}</h1>
      <p>{course.shortDescription}</p>

      {course.modules.map((module) => (
        // Client component for the toggle; server-rendered markup as children.
        <ExpandableSection key={module.slug} title={module.title}>
          <ul>
            {module.lessons.map((lesson) => (
              <li key={lesson.slug}>{lesson.title}</li>
            ))}
          </ul>
        </ExpandableSection>
      ))}

      <CompletionButton courseSlug={course.slug} />
    </article>
  );
}

// ExpandableSection.tsx
"use client";

import { useState, type ReactNode } from "react";

export function ExpandableSection({ title, children }: { title: string; children: ReactNode }) {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <section>
      <h2>
        <button type="button" onClick={() => setIsOpen((open) => !open)} aria-expanded={isOpen}>
          {title}
        </button>
      </h2>
      {isOpen && children}
    </section>
  );
}

Props that cross the boundary have to be written into the page as data for the browser to read back. A function is code with a scope around it — the variables it closed over, the modules it imported. There is no honest way to turn that into data and reconstruct it in another process.

The options, roughly in order of preference. Define the function in the client component, since formatting is browser-safe code that belongs where it is used. Or do the formatting on the server and pass the finished string, which sends less JavaScript. Or, if the function has to run on the server in response to something the user does, make it a server action — which works because the framework passes a reference the browser can call, not the function itself.

The general point is that the boundary is a process boundary. Anything crossing it is data in transit, which is also why a Date survives and a database row object with methods on it does not. Mapping server data to plain fields before passing it is a good habit regardless: it keeps the client component's inputs small and stops internal fields leaking into the page source.