2. Decide what one task contains

Open the existing React page or component that is intended for this lesson. If you are unsure which file to edit, inspect the project’s existing page/component files and follow the project’s documented development command rather than creating a new project.

Start with the smallest useful task shape. A task needs:

const exampleTask = {
  id: /* stable identifier */,
  title: /* text shown to the user */,
  completed: /* true or false */
};

const exampleTask = {
  id: /* stable identifier */,
  title: /* text shown to the user */,
  completed: /* true or false */
};

Use these meanings:

• id identifies the task independently of its position in the array.
• title is the user-facing task text.
• completed describes whether the task is finished.

The id matters because a task’s position can change when tasks are sorted, deleted, or filtered. React also needs a stable identity when rendering a list. The title should contain the task’s content, not markup. The completed value should be a boolean, not a string such as "false".

Now create a small collection using your own task text. Keep it to one or two objects for now:

const initialTasks = [
  {
    id: /* your first id */,
    title: /* your first task title */,
    completed: false
  }
  // Add a second task only if it helps you inspect the list layout.
];

const initialTasks = [
  {
    id: /* your first id */,
    title: /* your first task title */,
    completed: false
  }
  // Add a second task only if it helps you inspect the list layout.
];

Do not add fields such as priority, dueDate, or createdBy yet. Extra fields create decisions that the page does not use. A small shape is easier to understand and easier to change.

Checkpoint

Pause and inspect your data. Explain to yourself:

1. Which property would React use to distinguish two tasks?
2. Which property would be displayed?
3. Which property could later control a completed style or checkbox?

If you cannot answer one of these, adjust the object before building the page.

3. Build the outer page shell

In the relevant component, replace or extend the current page markup with a semantic outer structure. Use a skeleton like this, but choose the exact text and class names yourself:

return (
  <main className="todo-page">
    <header>
      <h1>{/* page title */}</h1>
      <p>{/* short description of what the page does */}</p>
    </header>

    {/* task form goes here */}

    <section aria-labelledby="task-list-heading">
      <h2 id="task-list-heading">{/* task section heading */}</h2>

      {/* task list or empty state goes here */}
    </section>
  </main>
);

return (
  <main className="todo-page">
    <header>
      <h1>{/* page title */}</h1>
      <p>{/* short description of what the page does */}</p>
    </header>

    {/* task form goes here */}

    <section aria-labelledby="task-list-heading">
      <h2 id="task-list-heading">{/* task section heading */}</h2>

      {/* task list or empty state goes here */}
    </section>
  </main>
);

The aria-labelledby connection is deliberate. It tells assistive technology that the section’s accessible name comes from the h2 with that ID. The visible heading and the accessibility information stay synchronized instead of describing the section twice.

Use a header for introductory content, but do not put every group inside a header. The main element should represent the page’s primary content, and the section should represent the distinct task area.

Visible check

Run the project using its documented command and open the page in the browser.

Then inspect the page with developer tools:

• Is there exactly one primary main region for this page?
• Does the page have a clear h1?
• Does the task area have its own heading?
• If you temporarily disable CSS, does the content still have a sensible order?

If the page is blank or the compiler reports an error, read the first error from the top. JSX errors often cause later lines to appear broken even though the real problem is earlier.

4. Add the task form

A form should describe the user’s action, even before submission works. Add the form inside the page shell:

<form>
  <label htmlFor="task-title">
    {/* label text */}
  </label>

  <input
    id="task-title"
    name="task-title"
    type="text"
    placeholder={/* short example, if useful */}
  />

  <button type="submit">
    {/* action text */}
  </button>
</form>

<form>
  <label htmlFor="task-title">
    {/* label text */}
  </label>

  <input
    id="task-title"
    name="task-title"
    type="text"
    placeholder={/* short example, if useful */}
  />

  <button type="submit">
    {/* action text */}
  </button>
</form>

Adapt the missing values to your page.

Three details are easy to overlook:

• htmlFor must match the input’s id. In JSX, use htmlFor, not HTML’s for.
• name gives the field a meaningful form control name.
• type="submit" makes the button’s purpose explicit.

Do not add a submit handler yet unless the existing project requires one to prevent a page reload. At this stage, the form’s job is to establish the interface and its relationships, not to pretend that task creation is complete.

A placeholder is not a label. A placeholder disappears when the user types and may be difficult to read. Keep the visible label.

Visible check

Use the browser to test the form structurally:

1. Click the label. Does focus move to the input?
2. Press Tab. Does focus reach the input and then the button in a sensible order?
3. With the input empty, what happens when you activate the button?

The last observation is useful even if you do not implement validation yet. The browser may submit the form or report no constraint; that behavior is a reminder that visual markup and interaction behavior are separate concerns.

5. Render the task list from the data shape

The task area should represent a collection as a real list. Use the existing initialTasks array rather than writing unrelated markup for every task.

A partial rendering shape could look like this:

<ul className="task-list">
  {initialTasks.map((task) => (
    <li key={/* stable task identifier */}>
      <label>
        <input
          type="checkbox"
          checked={/* task completion value */}
          readOnly
        />
        <span>{/* task title */}</span>
      </label>
    </li>
  ))}
</ul>

<ul className="task-list">
  {initialTasks.map((task) => (
    <li key={/* stable task identifier */}>
      <label>
        <input
          type="checkbox"
          checked={/* task completion value */}
          readOnly
        />
        <span>{/* task title */}</span>
      </label>
    </li>
  ))}
</ul>

Fill in the expressions using the properties of your task object.

Notice the relationship:

• The array describes what tasks exist.
• .map() turns each data object into one list item.
• key gives React a stable identity for that list item.
• The checkbox reflects completed.
• The text reflects title.

readOnly is appropriate for this static shell if the checkbox is controlled by a value but does not yet have a change handler. Without it, React may warn that the field is controlled but cannot be changed. You are not implementing completion behavior in this lesson; you are making the relationship visible.

Do not use the array index as the key just because it is available. If a task is removed later, the remaining tasks can shift positions, and index keys no longer represent the same task.

Visible check

With one or two tasks in initialTasks, verify:

• each object produces exactly one li
• the visible title matches the object’s title
• a task with completed: true starts checked
• the browser console has no React key warning

Change one task’s completed value and reload. The visible checkbox should change without changing the rendering code. That demonstrates that the page is using the data shape rather than hardcoded task markup.

6. Add the empty state

A task list also needs to explain what is happening when the collection is empty. Otherwise the user may see a heading followed by blank space and wonder whether the page failed.

Render either the list or an empty-state message based on the number of tasks:

{initialTasks.length > 0 ? (
  <ul className="task-list">
    {/* map the tasks here */}
  </ul>
) : (
  <p className="empty-state">
    {/* explain that there are currently no tasks */}
  </p>
)}

{initialTasks.length > 0 ? (
  <ul className="task-list">
    {/* map the tasks here */}
  </ul>
) : (
  <p className="empty-state">
    {/* explain that there are currently no tasks */}
  </p>
)}

The condition is based on the collection, not on a separate hasTasks value. That avoids two pieces of information drifting apart.

Temporarily change your data to:

const initialTasks = [];

const initialTasks = [];

Do not leave the list’s old static item outside the conditional. If you do, the empty state and the task item will appear together, which makes the page contradict itself.

Visible check

Reload with an empty array and confirm that:

• the task list is absent
• the empty-state message is visible
• the form and page headings remain visible
• the page still has a logical reading order

Then restore one task and confirm that the list returns. This is an important check: both branches should be valid page states, not just one successful screenshot.