Building the Dashboard Layout

Introduction: From Backend-Ready to a Real Frontend

Welcome back! 🎉 At this point, your Task Manager backend is complete and production-ready. All APIs live under src/app/api/**, and from here on out, we treat that backend as read-only. In these final courses, our entire focus shifts to the frontend UI—how users actually experience and interact with the system you’ve already built. In this lesson, you’ll take a blank Next.js app and progressively turn it into a real, navigable Task Manager interface. You’ll start by setting up global styling and a dashboard entry point, then add shared navigation, and finally connect the UI to live backend data. Along the way, you’ll practice giving clear, scoped Codex prompts that modify only the intended frontend files.

How This Lesson Fits Together

This lesson is structured around three small but meaningful frontend milestones: Establishing a styled application shell with Tailwind and a dashboard home page Introducing a shared dashboard layout with navigation and stable routes Fetching real task data from the existing API and rendering it in the UI Each practice builds directly on the previous one, and each change happens only in frontend files. Any file under src/app/api/** already works and must not be edited.

A Clear Boundary: Frontend vs Backend

Before we dive in, it’s important to internalize one rule that applies to every practice in this lesson: All backend logic lives in src/app/api/** . From now on, you will not modify anything in that directory. For example, src/app/api/tasks/route.ts already defines a working API. TypeScript export async function GET() {const tasks = await getAllTasks(); return createSuccessResponse(tasks);} This endpoint returns data in the shape { data: Task[], meta: { ... } } . The frontend’s job is simply to consume this API, not change it. All UI work happens in src/app/layout.tsx and src/app/(dashboard)/** . Keeping this boundary clear mirrors how real teams work and makes your Codex prompts much safer and more predictable.

Root layout and Tailwind setup

This code lives in src/app/layout.tsx . It defines the global HTML shell for your whole Next.js app—everything you render will be placed inside this layout. In this environment, Tailwind is provided via a CDN script, so this file is where we enable styling and set a clean default background/text so every page looks “app-like” immediately. TypeScript import { ReactNode } from 'react'; export default function RootLayout({ children }: { children: ReactNode }) {return (<html lang="en"> <head> <script src="https://cdn.tailwindcss.com"></script> </head> <body className="min-h-screen bg-gray-50 text-gray-900">{children}</body> </html>);} RootLayout is a special Next.js App Router component that wraps every page in your application. That’s why it’s the right place to load global resources and apply default styling—every route will inherit it automatically. The Tailwind CDN script is required in this sandbox environment so utility classes (like bg-gray-50) actually work. In a typical production app you’d install Tailwind via npm, but here the CDN keeps setup lightweight and predictable. The <body> classes create a consistent baseline look: min-h-screen prevents short pages from looking cut off bg-gray-50 and text-gray-900 create a clean, readable default theme

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Fetching tasks on the dashboard

This code lives in src/app/(dashboard)/page.tsx. We convert the page into a client component so it can use hooks, then fetch tasks and derive useful UI: counts and a “Recent Tasks” list.

TypeScript

'use client';

import Link from 'next/link';
import { useEffect, useMemo, useState } from 'react';
import type { Task } from '@/lib/tasks';

type ApiResponse<T> = { data: T; meta?: { timestamp?: string } };

function StatCard({ title, value }: { title: string; value: number }) {
  return (
    <div className="rounded-lg border bg-white p-4">
      <div className="text-sm text-gray-600">{title}</div>
      <div className="mt-1 text-2xl font-semibold">{value}</div>
    </div>
  );
}

'use client' tells Next.js this page runs on the client, which is required for hooks like useEffect and useState. Without it, Next.js treats the file as a server component and the hooks would be invalid.
Task is imported as a type from @/lib/tasks, which keeps your UI aligned with backend data shape (id/title/content/completed/dueDate). This helps prevent “guessing” fields and keeps your UI consistent with the project’s single source of truth.
StatCard is a small reusable React component. It’s just a function that returns JSX, and we’ll use it to render Total/Completed/Incomplete in a consistent style without repeating markup.

Now the page component that fetches and renders:

TypeScript

export default function DashboardHomePage() {
  const [tasks, setTasks] = useState<Task[]>([]);
  const [isLoading, setIsLoading] = useState<boolean>(true);
  const [error, setError] = useState<string>('');

  useEffect(() => {
    let cancelled = false;

    async function load() {
      try {
        setIsLoading(true);
        setError('');

        const res = await fetch('/api/tasks');
        if (!res.ok) throw new Error(`Request failed (${res.status})`);

        const json: ApiResponse<Task[]> = await res.json();
        const arr = Array.isArray(json.data) ? json.data : [];

        if (!cancelled) setTasks(arr);
      } catch (e: any) {
        if (!cancelled) setError(e?.message ?? 'Unknown error');
      } finally {
        if (!cancelled) setIsLoading(false);
      }
    }

    load();
    return () => {
      cancelled = true;
    };
  }, []);

  const stats = useMemo(() => {
    const total = tasks.length;
    const completed = tasks.filter((t) => t.completed).length;
    const incomplete = total - completed;
    return { total, completed, incomplete };
  }, [tasks]);

  const recent = tasks.slice(0, 5);

  return (
    <div className="space-y-6">
      <div className="flex items-center justify-between">
        <h1 className="text-2xl font-semibold">Dashboard</h1>
        <Link href="/tasks" className="text-sm text-blue-600 hover:underline">
          View all tasks →
        </Link>
      </div>

      <div className="grid grid-cols-1 gap-4 sm:grid-cols-3">
        <StatCard title="Total" value={stats.total} />
        <StatCard title="Completed" value={stats.completed} />
        <StatCard title="Incomplete" value={stats.incomplete} />
      </div>

      <section className="space-y-3">
        <h2 className="text-lg font-semibold">Recent Tasks</h2>

        {isLoading && <p className="text-gray-500">Loading tasks…</p>}
        {error && <p className="text-red-600">Failed to load tasks: {error}</p>}

        <div className="divide-y rounded-lg border bg-white">
          {!isLoading && !error && recent.length === 0 && (
            <div className="p-4 text-gray-500">No tasks yet.</div>
          )}

          {!isLoading &&
            !error &&
            recent.map((t) => (
              <div key={t.id} className="flex items-center justify-between p-4">
                <div className="font-medium">{t.title}</div>
                <span className={t.completed ? 'text-green-700' : 'text-yellow-700'}>
                  {t.completed ? 'Completed' : 'Pending'}
                </span>
              </div>
            ))}
        </div>
      </section>
    </div>
  );
}

useEffect is used to fetch on first render, because fetching is a side effect (it happens “because the component mounted,” not because the UI is rendering). This pattern is common for client-side data fetching and helps keep render logic clean.
We read the tasks array from json.data, which matches the backend response helper shape (createSuccessResponse). This detail matters: if you accidentally do setTasks(json), your UI will break because it expects an array, not an object.
Loading, error, and empty states make the UI resilient. Without these states, your dashboard would either look broken (blank) or crash when the network is slow or returns an error.
useMemo computes stats efficiently and clearly. It’s not strictly required for performance here, but it teaches a good habit: derived values (like counts) should be computed from state in one place, not duplicated across the UI.
Link gives users a path forward. Right now it connects your “summary dashboard” to the “full list page,” and later it becomes a key part of the app’s navigation story.

Fetching and rendering the full task list

This code lives in src/app/(dashboard)/tasks/page.tsx. It’s similar to the dashboard fetch, but the UI goal is different: show the entire list. Reusing the same fetch pattern across pages is a good sign—you’re building consistent UI behavior.

TypeScript

'use client';

import { useEffect, useState } from 'react';
import type { Task } from '@/lib/tasks';

type ApiResponse<T> = { data: T; meta?: { timestamp?: string } };

export default function TasksPage() {
  const [tasks, setTasks] = useState<Task[]>([]);
  const [isLoading, setIsLoading] = useState<boolean>(true);
  const [error, setError] = useState<string>('');

  useEffect(() => {
    let cancelled = false;

    async function load() {
      try {
        setIsLoading(true);
        setError('');

        const res = await fetch('/api/tasks');
        if (!res.ok) throw new Error(`Request failed (${res.status})`);

        const json: ApiResponse<Task[]> = await res.json();
        const arr = Array.isArray(json.data) ? json.data : [];

        if (!cancelled) setTasks(arr);
      } catch (e: any) {
        if (!cancelled) setError(e?.message ?? 'Unknown error');
      } finally {
        if (!cancelled) setIsLoading(false);
      }
    }

    load();
    return () => {
      cancelled = true;
    };
  }, []);

  return (
    <div className="space-y-6">
      <h1 className="text-2xl font-semibold">Tasks</h1>

      {isLoading && <p className="text-gray-500">Loading tasks…</p>}
      {error && <p className="text-red-600">Failed to load tasks: {error}</p>}

      <div className="divide-y rounded-lg border bg-white">
        {!isLoading && !error && tasks.length === 0 && (
          <div className="p-4 text-gray-500">No tasks yet.</div>
        )}

        {!isLoading &&
          !error &&
          tasks.map((t) => (
            <div key={t.id} className="flex items-center justify-between p-4">
              <div className="font-medium">{t.title}</div>
              <span className={t.completed ? 'text-green-700' : 'text-yellow-700'}>
                {t.completed ? 'Completed' : 'Pending'}
              </span>
            </div>
          ))}
      </div>
    </div>
  );
}

This page is also a client component, for the same reason as the dashboard: it needs hooks for fetching and state. Keeping both pages consistent makes the app easier to maintain as it grows.
The fetch logic is intentionally similar to the dashboard. In real projects you might extract a shared hook later, but early on it’s helpful to keep things explicit so you understand exactly what’s happening.
The list UI is “structure first”. Right now it shows title + status; later you’ll enrich rows with links, actions, and possibly inline updates, but this simple rendering proves data flow is correct.
The empty state is critical for first-time users. When the API returns an empty array, you still want the UI to feel intentional—not broken—so the “No tasks yet” message gives a friendly starting point.

Introduction: From Backend-Ready to a Real Frontend

How This Lesson Fits Together

A Clear Boundary: Frontend vs Backend

Root layout and Tailwind setup

Join the 1M+ learners on CodeSignal

The dashboard home page

Creating a Shared Dashboard Layout with Navigation

Placeholder pages for navigation targets

Connecting the UI to Live Task Data

Fetching tasks on the dashboard

Fetching and rendering the full task list

Writing Strong Codex Prompts

Recap