To-Do With Filter Tabs

A task list with three filter tabs — In progress, Completed and Deleted — and Enter to add.

The third tab is the entire exercise, and it is the requirement people skim past. A to-do list where deleting means filter(t => t.id !== id) cannot show a Deleted tab at all, so the data model has to be right before any of the UI works.

One status field rather than two booleans is the call to make. With isCompleted and isDeleted you can represent a task that is both, which means every filter has to decide what that means — and different parts of the code will decide differently. A single status of in-progress, completed or deleted makes the invalid combination impossible to write down.

Everything else follows from that. The visible list is derived by filtering at render time, the per-tab counts are derived the same way, and every action is one map that replaces a task with a copy carrying a new status. No action needs to know about any other tab, and nothing is ever spliced out of the array.

It is the easiest of these problems and still a real test, because the modelling mistake is available and tempting. A reasonable follow-up is persistence, and the shape already suits it: one array of self-describing tasks serialises directly.