The data model, derived values and the state plan
Four tasks are stored; everything else is computed from them and the filters. Change filters.q to "" and every task is visible again: derived values can't go stale.
Before writing code, plan the task board with the RADIO steps from Phase 25: list the requirements, sketch a mockup, turn it into a component tree, decide what is state and where it lives, and design the data model and API.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write the state table rows for a new feature: a "Show only my tasks" toggle and a task assignee field.
Write the action objects for: adding "Fix bug", moving t3 to Done, and deleting t1.
Explain it without notes
Walk through how you'd plan a task board before coding.
Why keep tasks in one flat array instead of one array per column?
Where should the search text live, and why?
What is a derived value? Give two in the task board.
Preview
Console
Nothing logged yet.Expected console output
stored tasks: 4
visible after the filter: [ 't3' ]
count per column: { todo: 1, doing: 0, done: 0 }