Keep One Source of Truth

Before moving into task actions, pause and check the data architecture.

The application should have one authoritative task list in App:

text

App
└── tasks
    ├── task 1
    ├── task 2
    └── task 3

The columns and cards should derive what they display from that list.

Avoid duplicated state

You do not need:

text

todoTasks
progressTasks
doneTasks

Those values can become inconsistent. A task could accidentally exist in two places or disappear from one list.

Instead, use the task’s status to derive its column.

Why this helps with actions

Later, deleting a task means producing a new tasks array without that task. Moving a task means producing a new array where that task has a different status.

The components then re-render from the updated array.

Checkpoint

You are ready for the next module if you can explain this sentence:

Actions change the task state; components render whatever the current state says.

In the next module, we will use that idea to make the form and task cards interactive.