Task Creation and Editing

Introduction: Turning CRUD Into a Real Product Experience

In Unit 1, you built the foundations that make CRUD pleasant instead of painful. You now have a reusable Input primitive, a reusable TaskForm with validation intent, a central API client that understands the backend { data, meta } envelope, and toast feedback so actions feel intentional instead of silent. Now in this lesson, you’ll take the next step: true interactivity. By the end of this lesson, your Task Manager will feel much more like a real app. Users will be able to create tasks and land back on the list, edit tasks directly from the detail page, and toggle completion from the list with updates that feel immediate. That shift matters because CRUD is not only about sending requests successfully. It is about giving users a smooth sense that the interface is reacting to what they do. As always, one important boundary stays in place: don’t touch src/app/api/** . The backend is read-only. Your job in this lesson is to build the frontend product layer on top of it, using the API contract that already exists.

Quick Recall: The Pattern We’re Repeating

Almost everything in this lesson follows the same product-grade loop. First, collect validated values with TaskForm . Then call the backend through api . After that, show toast feedback for success or failure, revalidate the pages that display tasks with mutate(...), and navigate the user to the next sensible screen when appropriate. That is the difference between “it works” and “it feels like an app.” A page that only submits data may be technically correct, but a page that also refreshes stale views, shows feedback, and moves the user forward feels polished and trustworthy. You will repeat that same loop several times in this lesson, which is why building the reusable primitives first was so important.

Practice 1: Production-Ready Create Flow (/tasks/new)

Join the 1M+ learners on CodeSignal

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

Practice 2: Real Edit Page (/tasks/[id])

This code block turns the detail route into an actual edit page. It fetches the task by id with SWR + api.get, pre-fills TaskForm, submits updates through api.put, and revalidates both the list and the specific task view.

TypeScript

// src/app/(dashboard)/tasks/[id]/page.tsx
"use client";

import { useParams } from "next/navigation";
import useSWR, { mutate } from "swr";
import { api } from "@/lib/apiClient";
import { TaskForm, TaskFormValues } from "@/components/tasks/TaskForm";
import { useToast } from "@/components/ui/Toast";

export default function TaskDetailPage() {
  const { id } = useParams<{ id: string }>();
  const toast = useToast();
  const key = `/api/tasks/${id}`;
  const { data: task, error, isLoading } = useSWR(key, api.get<any>);

  const handleUpdate = async (values: TaskFormValues) => {
    const res = await api.put(key, {
      ...values,
      completed: task?.completed ?? false,
    });
    if ("error" in res) {
      toast.error("Failed to update");
      return;
    }
    toast.success("Task updated");
    mutate("/api/tasks");
    mutate(key);
  };

  if (isLoading) return <div className="text-gray-500">Loading…</div>;
  if (error || !task) return <div className="text-red-600">Task not found</div>;

  return (
    <div className="space-y-6">
      <h1 className="text-2xl font-semibold">Edit Task</h1>
      <div className="rounded-lg border bg-white p-4">
        <TaskForm
          initialValues={task}
          onSubmit={handleUpdate}
          submitLabel="Save"
        />
      </div>
    </div>
  );
}

// src/app/(dashboard)/tasks/[id]/page.tsx
"use client";

import { useParams } from "next/navigation";
import useSWR, { mutate } from "swr";
import { api } from "@/lib/apiClient";
import { TaskForm, TaskFormValues } from "@/components/tasks/TaskForm";
import { useToast } from "@/components/ui/Toast";

export default function TaskDetailPage() {
  const { id } = useParams<{ id: string }>();
  const toast = useToast();
  const key = `/api/tasks/${id}`;
  const { data: task, error, isLoading } = useSWR(key, api.get<any>);

  const handleUpdate = async (values: TaskFormValues) => {
    const res = await api.put(key, {
      ...values,
      completed: task?.completed ?? false,
    });
    if ("error" in res) {
      toast.error("Failed to update");
      return;
    }
    toast.success("Task updated");
    mutate("/api/tasks");
    mutate(key);
  };

  if (isLoading) return <div className="text-gray-500">Loading…</div>;
  if (error || !task) return <div className="text-red-600">Task not found</div>;

  return (
    <div className="space-y-6">
      <h1 className="text-2xl font-semibold">Edit Task</h1>
      <div className="rounded-lg border bg-white p-4">
        <TaskForm
          initialValues={task}
          onSubmit={handleUpdate}
          submitLabel="Save"
        />
      </div>
    </div>
  );
}

SWR makes the edit page data-aware. The page has explicit loading and error states, which means it can respond appropriately before the task data arrives and if something goes wrong. Once the task is available, that data becomes the initialValues for the form, which gives the edit experience its “prefilled” feel.
api.put(key, ...) uses the same resource path that the page fetched. That keeps the mental model simple: the task you loaded is the task you are updating. When the fetch key and update target line up cleanly, the flow becomes easier to reason about and easier to maintain.
Two revalidations keep the UI consistent across views. mutate("/api/tasks") refreshes the list page, while mutate(key) refreshes the current detail page. That way, both the broader list UI and the local edit page stay accurate after saving changes.

This page is where the value of TaskForm really starts to show. You do not build a separate edit form from scratch. Instead, the page only needs to fetch the current task, pass those values into the reusable form, and define what should happen when the user saves.

Practice 3: Instant Completion Toggle (Optimistic UI in TaskRow)

This code block adds a completion toggle directly in each TaskRow and makes the interaction feel instant. The UI updates optimistically first, then calls the backend with api.patch, and finally revalidates the relevant caches, including filtered task views when those keys are provided.