Task Filters and Toasts

Introduction: Let the URL Drive the UI

Welcome back! 🙌 At this point, your Task Manager UI already feels like a real app. It has a dashboard shell, consistent task rows, reusable buttons, and pages that fetch live task data from the backend. In this final unit, you’ll make the UI feel smarter by letting the URL control what the user sees. This is an important idea in modern web apps because the URL is not just an address bar detail — it can also act as part of your application state. When the URL changes, the UI can react to it, which makes views shareable, bookmarkable, and easier to understand. There are three main improvements in this unit. First, you’ll build a proper Filtered Tasks view that reads a query param (completed=true|false), validates it, fetches the matching data, and renders results using your existing TaskRow component. Next, you’ll polish the stub routes so they feel more intentional, even though full CRUD is not implemented yet. Finally, you’ll add a lightweight toast notification system so even a temporary page can give the user friendly, app-like feedback. Together, these changes make the UI feel more dynamic and more product-like without requiring any backend changes.

Previously…

In the previous unit, you extracted repeated markup into reusable components like TaskRow and Button, and you wired up navigation so /tasks/new and /tasks/[id] routes already exist. That gave the app a stronger internal structure and made the UI more consistent across pages. Now you’ll build on top of that structure with URL-driven filtering, stronger product-style stub pages, and a toast system for small but meaningful feedback. These are the kinds of additions that make an app feel more polished, even before all of its features are complete. And as always, one rule remains unchanged: the backend lives under src/app/api/** and is read-only for this course unit. You should not modify it. Your job is to consume the existing backend cleanly and build the frontend around the API contract it already provides.

Keeping Frontend and Backend Separate

Your UI consumes endpoints that already exist. In this unit, you’ll specifically rely on: GET /api/tasks/filter?completed=true|false \to { data: Task[] } This matters for two reasons. First, the backend expects exact string values: "true" or "false" . That means your frontend should not invent alternate values like "yes", "0", or booleans in the URL. Second, the backend wraps its returned task array inside an object, so you must read tasks from json.data instead of assuming the response itself is the array. If your UI validates correctly and fetches correctly, the same filter page will continue to work no matter how many tasks exist or how the list changes over time. That is one of the benefits of keeping frontend and backend responsibilities cleanly separated: each side stays predictable.

Join the 1M+ learners on CodeSignal

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

TaskFilters component

This code lives in src/components/tasks/TaskFilters.tsx. It renders two reusable Buttons, highlights the selected filter based on the URL, and updates the URL when the user clicks a filter.

TypeScript

'use client';

import { useRouter, useSearchParams } from 'next/navigation';
import { Button } from '@/components/ui/Button';

export function TaskFilters() {
  const router = useRouter();
  const params = useSearchParams();
  const completed = params.get('completed') || 'false';

  return (
    <div className="inline-flex rounded-md border bg-white p-1 gap-1">
      <Button
        type="button"
        variant={completed === 'false' ? 'primary' : 'secondary'}
        onClick={() => router.push('/tasks/filter?completed=false')}
      >
        Incomplete
      </Button>

      <Button
        type="button"
        variant={completed === 'true' ? 'primary' : 'secondary'}
        onClick={() => router.push('/tasks/filter?completed=true')}
      >
        Completed
      </Button>
    </div>
  );
}

This is a client component because it uses hooks like useRouter and useSearchParams. In Next.js App Router, those hooks are only available in client components, which is why the file needs the 'use client' directive. This is a common pattern whenever a component reacts directly to navigation state.
useSearchParams() makes the URL the source of truth for which filter is currently active. That means the buttons do not need their own separate state, because the selected value is already encoded in the query string. This is one of the cleanest examples of URL-driven UI: the interface reflects what the URL says, rather than maintaining an independent copy of the same information.
router.push(...) updates the URL without a full page reload, which keeps the app feeling fast and smooth. It also means changing the filter behaves like real app navigation rather than like a traditional full-page refresh. Once you get used to this pattern, it becomes a very natural way to build filter views, tabs, and other navigation-driven UI.

This component is small, but it solves a very real problem elegantly. It gives you stateful behavior without extra complexity, because the URL itself carries the state.

Rendering Filtered Tasks with Query Validation

Now we’ll turn /tasks/filter into a real page. This page needs to read completed from the URL, validate it, fetch from /api/tasks/filter?completed=..., render a list with TaskRow, and show loading, error, and empty states just like the rest of your task views.

This code lives in src/app/(dashboard)/tasks/filter/page.tsx. It ties together the filter controls, the validation logic, and the filtered fetch request.

TypeScript

'use client';

import { useEffect, useState } from 'react';
import { useSearchParams } from 'next/navigation';
import type { Task } from '@/lib/tasks';
import { TaskRow } from '@/components/tasks/TaskRow';
import { TaskFilters } from '@/components/tasks/TaskFilters';

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

export default function FilterPage() {
  const params = useSearchParams();
  const completed = params.get('completed') || 'false';

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

  useEffect(() => {
    let alive = true;

    const run = async () => {
      setIsLoading(true);
      setError('');

      if (completed !== 'true' && completed !== 'false') {
        setError("Query param 'completed' must be 'true' or 'false'.");
        setIsLoading(false);
        return;
      }

      try {
        const res = await fetch(`/api/tasks/filter?completed=${completed}`, {
          cache: 'no-store',
        });
        if (!res.ok) throw new Error(`Request failed (HTTP ${res.status})`);

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

        if (alive) setTasks(next);
      } catch (e) {
        if (!alive) return;
        setError(e instanceof Error ? e.message : 'Unknown error');
      } finally {
        if (alive) setIsLoading(false);
      }
    };

    run();
    return () => {
      alive = false;
    };
  }, [completed]);

  return (
    <div className="space-y-6">
      <div className="flex items-center justify-between">
        <h1 className="text-2xl font-semibold">Filtered Tasks</h1>
        <TaskFilters />
      </div>

      {isLoading && <p className="text-gray-500">Loading filtered 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 match this filter.</div>
        )}

        {!isLoading &&
          !error &&
          tasks.map((t) => <TaskRow key={t.id} task={t} />)}
      </div>
    </div>
  );
}

The query param is validated before the fetch happens, which prevents unnecessary requests and gives the user a clear message if they manually type an invalid URL. This is important because URLs are user input too. A lot of frontend bugs happen when code assumes the URL will always contain the “right” value, but in real apps users can edit it directly.
The page fetches from /api/tasks/filter and parses tasks from json.data, matching the backend contract exactly. That detail matters a lot. If you accidentally tried to use json itself as the array, your rendering logic would break because you would be working with the wrapper object instead of the real task list.
useEffect depends on [completed], so changing the URL automatically triggers a new fetch. This is the heart of URL-driven UI: navigation updates the URL, the URL determines state, and state determines what data gets loaded. Once those pieces line up cleanly, the page becomes very easy to reason about.

This page is a great example of how a small query param can control a meaningful piece of UI behavior while keeping the code understandable.

Making Sure the Sidebar Filters Link Works

Once the filter page exists, your layout should send users to a sensible default filter when they click “Filters.” In this unit, that default is /tasks/filter?completed=false.

This code lives in src/app/(dashboard)/layout.tsx. The important pieces are the Filters href and the active-state rule that recognizes filter routes.

TypeScript

'use client';

import Link from 'next/link';
import { ReactNode } from 'react';
import { usePathname } from 'next/navigation';

const navItems = [
  { href: '/', label: 'Dashboard' },
  { href: '/tasks', label: 'Tasks' },
  { href: '/tasks/filter?completed=false', label: 'Filters' },
];

export default function DashboardLayout({ children }: { children: ReactNode }) {
  const pathname = usePathname();

  const isActive = (href: string) => {
    if (href === '/') return pathname === '/';
    if (href.startsWith('/tasks/filter')) return pathname.startsWith('/tasks/filter');
    if (href === '/tasks') return pathname === '/tasks' || pathname.startsWith('/tasks/');
    return pathname === href;
  };

  return (
    <div className="min-h-screen grid grid-cols-1 md:grid-cols-[240px_1fr]">
      <aside className="hidden md:block border-r bg-white">
        <div className="p-4 text-xl font-semibold">TaskManager</div>

        <nav className="px-2 space-y-1">
          {navItems.map((item) => {
            const active = isActive(item.href);
            return (
              <Link
                key={item.href}
                href={item.href}
                className={
                  'block rounded-md px-3 py-2 text-sm font-medium transition-colors ' +
                  (active
                    ? 'bg-blue-50 text-blue-700'
                    : 'text-gray-700 hover:bg-gray-100 hover:text-gray-900')
                }
              >
                {item.label}
              </Link>
            );
          })}
        </nav>
      </aside>

      <main className="p-4 md:p-6 lg:p-8">
        <div className="mx-auto max-w-5xl">{children}</div>
      </main>
    </div>
  );
}

The sidebar uses Link from next/link, which gives client-side navigation and helps preserve the smooth dashboard experience. Since the Filters destination is a normal navigation item in the layout, Link is the natural fit here.
The Filters link includes a default query string so users land on a meaningful page immediately. Without that default, the route would be less clear because the page logic depends on a specific filter value. Choosing a default incomplete-tasks view gives the section a sensible starting state.
The active-state logic checks pathname.startsWith('/tasks/filter'), which correctly keeps “Filters” highlighted even if the query string changes. This works because usePathname() only returns the path portion of the URL, not the query string. Understanding that behavior helps you write active-route matching that feels correct to users.

Adding Toast Feedback Across the Dashboard

Toasts are a small but very useful UX primitive. They let the app communicate feedback without requiring a full page refresh or a large modal. Even when a page is still a stub, a toast can acknowledge an action and make the interface feel responsive.

We’ll implement a ToasterProvider that stores toasts in state, a useToast() hook with success, error, and info helpers, automatic dismissal after about 2.5 seconds, and a fixed top-right stack for rendering notifications.

This code lives in src/components/ui/Toast.tsx. It provides toast functionality through React context and renders the visible toast stack.

TypeScript

'use client';

import {
  createContext,
  ReactNode,
  useCallback,
  useContext,
  useMemo,
  useState,
} from 'react';

type ToastType = 'success' | 'error' | 'info';

type Toast = {
  id: number;
  message: string;
  type: ToastType;
};

type ToastApi = {
  success: (msg: string) => void;
  error: (msg: string) => void;
  info: (msg: string) => void;
};

const ToastContext = createContext<ToastApi | null>(null);

export function ToasterProvider({ children }: { children: ReactNode }) {
  const [toasts, setToasts] = useState<Toast[]>([]);

  const push = useCallback((message: string, type: ToastType) => {
    const id = Date.now() + Math.floor(Math.random() * 1000);

    setToasts((prev) => [...prev, { id, message, type }]);

    window.setTimeout(() => {
      setToasts((prev) => prev.filter((t) => t.id !== id));
    }, 2500);
  }, []);

  const api = useMemo<ToastApi>(
    () => ({
      success: (m) => push(m, 'success'),
      error: (m) => push(m, 'error'),
      info: (m) => push(m, 'info'),
    }),
    [push]
  );

  const typeClass = (t: ToastType) => {
    if (t === 'success') return 'border-green-200 bg-green-50 text-green-900';
    if (t === 'error') return 'border-red-200 bg-red-50 text-red-900';
    return 'border-gray-200 bg-white text-gray-900';
  };

  return (
    <ToastContext.Provider value={api}>
      {children}

      <div className="fixed top-4 right-4 space-y-2 z-50">
        {toasts.map((t) => (
          <div
            key={t.id}
            className={`rounded-md border px-3 py-2 text-sm shadow ${typeClass(t.type)}`}
          >
            {t.message}
          </div>
        ))}
      </div>
    </ToastContext.Provider>
  );
}

export function useToast(): ToastApi {
  const ctx = useContext(ToastContext);
  if (!ctx) throw new Error('useToast must be used within ToasterProvider');
  return ctx;
}

This uses React context so any dashboard page can show a toast without passing functions through multiple component levels. That is the main reason to introduce a provider here. Toasts are a cross-page UI feature, so centralizing them makes the rest of the app much simpler.
push() adds a toast and schedules its removal, which creates the auto-dismiss behavior users expect from lightweight notifications. Putting that timing behavior inside one shared function keeps the experience consistent everywhere. Pages do not need to manage timeout logic themselves — they only ask to show a message.
The fixed top-right stack makes notifications predictable and keeps them separate from page layout. Because the toast container is outside the normal document flow, it does not push page content around. That makes it a good fit for short feedback that should be noticeable without disrupting the rest of the UI.

Wrapping the Dashboard Layout with ToasterProvider

Toasts should work in every dashboard route, so the best place to mount the provider is the dashboard layout itself. That way, every page inside (dashboard) can use useToast() without setting up its own provider.

This code lives in src/app/(dashboard)/layout.tsx. The layout keeps its sidebar shell, but now wraps everything in <ToasterProvider>.

TypeScript

'use client';

import Link from 'next/link';
import { ReactNode } from 'react';
import { usePathname } from 'next/navigation';
import { ToasterProvider } from '@/components/ui/Toast';

const navItems = [
  { href: '/', label: 'Dashboard' },
  { href: '/tasks', label: 'Tasks' },
  { href: '/tasks/filter?completed=false', label: 'Filters' },
];

export default function DashboardLayout({ children }: { children: ReactNode }) {
  const pathname = usePathname();

  const isActive = (href: string) => {
    if (href === '/') return pathname === '/';
    if (href.startsWith('/tasks/filter')) return pathname.startsWith('/tasks/filter');
    if (href === '/tasks') return pathname === '/tasks' || pathname.startsWith('/tasks/');
    return pathname === href;
  };

  return (
    <ToasterProvider>
      <div className="min-h-screen grid grid-cols-1 md:grid-cols-[240px_1fr]">
        <aside className="hidden md:block border-r bg-white">
          <div className="p-4 text-xl font-semibold">TaskManager</div>

          <nav className="px-2 space-y-1">
            {navItems.map((item) => {
              const active = isActive(item.href);
              return (
                <Link
                  key={item.href}
                  href={item.href}
                  className={
                    'block rounded-md px-3 py-2 text-sm font-medium transition-colors ' +
                    (active
                      ? 'bg-blue-50 text-blue-700'
                      : 'text-gray-700 hover:bg-gray-100 hover:text-gray-900')
                  }
                >
                  {item.label}
                </Link>
              );
            })}
          </nav>
        </aside>

        <main className="p-4 md:p-6 lg:p-8">
          <div className="mx-auto max-w-5xl">{children}</div>
        </main>
      </div>
    </ToasterProvider>
  );
}

Wrapping at the layout level means the toast system is mounted once for the whole dashboard, not separately for each page. That is important because it keeps the toast system stable during navigation and avoids unnecessary reinitialization.
This is the right level for global UI concerns, just like navigation shells or theme providers. Toasts are not specific to one page; they are part of the overall app experience. Putting them in the layout reflects that responsibility clearly.
This change still respects the course boundary that the backend is read-only. The provider only affects frontend infrastructure. It does not alter routes, API handlers, or data contracts. That makes it a good example of adding UI capability without touching backend logic.

Triggering a Toast from the New Task Stub Page

Now we’ll prove the toast system works by adding a button that triggers an info toast. This gives the stub page a small but meaningful interaction and helps it feel intentional instead of unfinished.

This code lives in src/app/(dashboard)/tasks/new/page.tsx. It becomes a client component so it can call useToast(), and the button displays a friendly message.

TypeScript

'use client';

import Link from 'next/link';
import { Button } from '@/components/ui/Button';
import { useToast } from '@/components/ui/Toast';

export default function NewTaskPage() {
  const toast = useToast();

  return (
    <div className="space-y-4">
      <h1 className="text-2xl font-semibold">Create Task</h1>

      <p className="text-gray-600">
        This page is intentionally a stub in Part 1. In Part 2, we’ll build a real form and
        call <code className="rounded bg-gray-100 px-1">POST /api/tasks</code>.
      </p>

      <Button
        type="button"
        onClick={() => toast.info('Task creation form is coming in Part 2!')}
      >
        Why can’t I create a task yet?
      </Button>

      <Link href="/tasks" className="block text-blue-600 hover:underline">
        ← Back to Tasks
      </Link>
    </div>
  );
}

This must be a client component because useToast() is a hook and depends on React context. In App Router, hooks require 'use client', so the page has to opt into client-side behavior in order to use the toast API.
The toast message is a small UX micro-interaction, but it has real value. Instead of leaving the page feeling passive, it acknowledges the user’s action and explains why the feature is not available yet. Small interactions like this help the app feel deliberately staged rather than incomplete.
The message also points directly toward future behavior by mentioning the eventual POST /api/tasks flow. That helps learners connect the current stub to the next unit’s implementation. In a project course, this kind of continuity makes the learning path feel much more coherent.

Introduction: Let the URL Drive the UI

Previously…

Keeping Frontend and Backend Separate

Join the 1M+ learners on CodeSignal

Building Filter Controls That Update the URL

TaskFilters component

Rendering Filtered Tasks with Query Validation

Making Sure the Sidebar Filters Link Works

Polishing Stub Routes to Feel Intentional

Adding Toast Feedback Across the Dashboard

Wrapping the Dashboard Layout with ToasterProvider

Triggering a Toast from the New Task Stub Page

Codex Prompts for This Unit

Recap