Forms and API Basics

Introduction: Welcome to Part 2 — Real CRUD Starts Here

Welcome to Vibe Coding the Frontend: Task Manager CRUD & UX Polish (Part 2) 🎉 In Part 1, you built a strong UI foundation. You now have a dashboard shell with navigation, reusable components like TaskRow and Button, URL-driven filtering, polished stub routes, and a lightweight toast system that already makes the app feel more interactive. In Unit 1: Forms and API Basics, you’ll start building the pieces that make real CRUD flows clean and consistent. Instead of jumping straight into large create and edit pages, you’ll first build the reusable primitives those pages depend on. That includes a reusable Input primitive with label, error handling, and ref forwarding, a reusable TaskForm that defines the shape and validation of task data, and a small API client wrapper so fetch(...) logic is not scattered across the codebase. These building blocks matter because the next two units will use them repeatedly. Once they exist, you can implement full task creation and editing more cleanly, and then move into delete flow and UX polish without rewriting form and request logic in every page. This is the same philosophy you used in Part 1: build small reusable pieces first, then use them to make the app feel real.

Previously: Where We Left Off (End of Part 1)

In the previous unit, you let the URL drive the UI. Filter buttons updated /tasks/filter?completed=true|false, the filter page validated query params and rendered filtered lists using TaskRow, stub routes were upgraded so they felt intentional instead of broken, and a toast system added friendly feedback across the dashboard. That matters because Part 2 keeps the same overall philosophy. You are still aiming for small reusable primitives, predictable data flow, and clear boundaries between frontend and backend. The frontend consumes src/app/api/**, but it does not rewrite it. The goal is not just to make CRUD “work,” but to make it work in a way that stays organized as the project grows.

Practice 1: Reusable Input Primitive

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: TaskForm Shell (React Hook Form + Zod)

This code block creates TaskForm, the reusable form component that will power both create and edit flows later. It defines the form shape the backend expects, validates it with Zod, and uses your shared Input and Button components so the UI stays consistent.

TypeScript

// src/components/tasks/TaskForm.tsx
"use client";
import { useForm } from "react-hook-form";
import { z } from "zod";
import { zodResolver } from "@hookform/resolvers/zod";
import { Input } from "@/components/ui/Input";
import { Button } from "@/components/ui/Button";

const schema = z.object({
  title: z.string().min(1, "Title is required"),
  content: z.string().min(1, "Content is required"),
  dueDate: z.string().optional(),
});

export type TaskFormValues = z.infer<typeof schema>;

export function TaskForm({
  initialValues,
  onSubmit,
  submitLabel = "Save",
}: {
  initialValues?: Partial<TaskFormValues>;
  onSubmit: (values: TaskFormValues) => Promise<void> | void;
  submitLabel?: string;
}) {
  const {
    register,
    handleSubmit,
    formState: { errors, isSubmitting },
  } = useForm<TaskFormValues>({
    resolver: zodResolver(schema),
    defaultValues: { title: "", content: "", dueDate: "", ...initialValues },
  });

  return (
    <form
      className="space-y-4"
      onSubmit={handleSubmit(async (v) => await onSubmit(v))}
    >
      <div>
        <Input
          label="Title"
          id="title"
          placeholder="Task title"
          {...register("title")}
        />
        {errors.title && (
          <p className="mt-1 text-sm text-red-600">{errors.title.message}</p>
        )}
      </div>

      <div>
        <label className="block text-sm">
          <span className="mb-1 block text-gray-700" htmlFor="content">
            Content
          </span>
          <textarea
            id="content"
            className="w-full rounded-md border border-gray-300 bg-white px-3 py-2 text-gray-900 placeholder-gray-400 focus:border-blue-500 focus:outline-none focus:ring-2 focus:ring-blue-500/30"
            rows={4}
            placeholder="Describe the task"
            {...register("content")}
          />
        </label>
        {errors.content && (
          <p className="mt-1 text-sm text-red-600">{errors.content.message}</p>
        )}
      </div>

      <div>
        <Input
          label="Due date"
          id="dueDate"
          type="date"
          {...register("dueDate")}
        />
        {errors.dueDate && (
          <p className="mt-1 text-sm text-red-600">{errors.dueDate.message}</p>
        )}
      </div>

      <div className="flex gap-2">
        <Button type="submit" disabled={isSubmitting}>
          {submitLabel}
        </Button>
      </div>
    </form>
  );
}

Zod defines the contract for the form values. It enforces that title and content are required while keeping dueDate optional, which means the UI can reject invalid input before any request is sent to the backend. That improves user experience and keeps bad data from reaching your API layer unnecessarily.
React Hook Form handles the mechanics of wiring inputs into form state and tracking submission behavior. register(...) connects each field to the form system, and isSubmitting gives you a reliable way to disable the submit button while work is in progress. That prevents double submits and gives the form a more polished feel.
The form is intentionally reusable. initialValues allows edit flows to prefill the fields later, while submitLabel lets different pages use the same form UI for slightly different actions, like “Create” versus “Save changes.” That is the key reason to extract a shared form shell now instead of waiting until both create and edit pages are written separately.

This component creates a strong boundary between form structure and page-specific behavior. The page decides what should happen on submit, but TaskForm owns how the task form itself behaves and looks.

Practice 3: API Client Wrapper (So Fetch Isn’t Everywhere)

This code block creates a small API client that standardizes how the frontend calls backend endpoints. It always parses JSON, extracts json.data from the backend envelope, and provides helper methods for the common HTTP verbs you’ll use in CRUD flows.

TypeScript

// src/lib/apiClient.ts
type ApiError = { error: string; status: number };

async function readJson(res: Response): Promise<any> {
  try {
    return await res.json();
  } catch {
    return {};
  }
}

function toMessage(x: any): string {
  if (typeof x === "string") return x;
  if (x instanceof Error) return x.message;
  try {
    return JSON.stringify(x);
  } catch {
    return "Unknown error";
  }
}

async function request<T>(
  url: string,
  init?: RequestInit
): Promise<{ ok: true; data: T } | { ok: false; error: ApiError }> {
  const res = await fetch(url, init);
  if (res.status === 204) {
    // No content
    return { ok: true, data: null as any };
  }
  const json = await readJson(res);
  if (!res.ok) {
    return {
      ok: false,
      error: {
        error: toMessage(json.error ?? `Request failed (${res.status})`),
        status: res.status,
      },
    };
  }
  return { ok: true, data: json.data as T };
}

export const api = {
  async get<T>(url: string): Promise<T> {
    const r = await request<T>(url);
    if (!r.ok) throw new Error(r.error.error);
    return r.data;
  },

  async post<T>(url: string, body: unknown): Promise<T | { error: string }> {
    const r = await request<T>(url, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(body),
    });
    return r.ok ? r.data : { error: r.error.error };
  },

  async put<T>(url: string, body: unknown): Promise<T | { error: string }> {
    const r = await request<T>(url, {
      method: "PUT",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(body),
    });
    return r.ok ? r.data : { error: r.error.error };
  },

  async patch<T>(url: string, body: unknown): Promise<T | { error: string }> {
    const r = await request<T>(url, {
      method: "PATCH",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(body),
    });
    return r.ok ? r.data : { error: r.error.error };
  },

  async del(url: string): Promise<{} | { error: string }> {
    const r = await request<{}>(url, { method: "DELETE" });
    return r.ok ? {} : { error: r.error.error };
  },
};

The client matches the backend response envelope. Since your API returns objects like { data, meta }, request() consistently extracts json.data so pages do not need to remember that detail every time they fetch. This is a small abstraction, but it removes a very common source of repetitive mistakes.
Errors are normalized into a predictable structure. Instead of every page inventing its own try/catch logic and manually digging through response payloads, the wrapper turns failures into something consistent. That makes downstream UI work easier, especially when you want to show toast messages for success and failure without reimplementing error parsing everywhere.
A shared API layer makes later units faster and cleaner. In Unit 2 and Unit 3, create, edit, and delete pages can focus on flow and user experience rather than on rebuilding the same fetch boilerplate over and over. This is exactly the kind of abstraction that pays off more as the app grows.

The wrapper is intentionally small. Its job is not to become a huge networking system — just to encode the rules your frontend already follows so the rest of the code can stay simpler.

Introduction: Welcome to Part 2 — Real CRUD Starts Here

Previously: Where We Left Off (End of Part 1)

Practice 1: Reusable Input Primitive

Join the 1M+ learners on CodeSignal

Codex prompting for this practice

Practice 2: TaskForm Shell (React Hook Form + Zod)

Codex prompting for this practice

Practice 3: API Client Wrapper (So Fetch Isn’t Everywhere)

Codex prompting for this practice

What You’ll Have After This Unit