The archive: 5,000 tasks, about 15 rows in the DOM
At the top, 10 visible rows + 3 overscan below = 13. In the middle, 3 above + about 10 visible + 3 below = 16. Scroll it yourself and inspect the list: rows are reused, never 5,000 of them.
Milestone 4: search and priority filters live in the URL, tasks load from a slow fake API with loading, error and retry states, moves are optimistic and roll back when the server fails, and a 5,000-task archive renders only the rows you can see.
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.
Add a sort search param (?sort=title) that sorts the visible tasks by title when set.
Change useLoadTasks to also expose the time of the last successful load as a fixed-format string.
Explain it without notes
Why put filters in the URL, and how do you update a search param without breaking the Back button?
Walk through an optimistic update with rollback. What can go wrong?
How do you model loading, error and retry for a request in React?
Explain how a fixed-height virtualised list works.
Preview
Console
Nothing logged yet.Expected console output
rows in the DOM: 13
after scrolling, rows in the DOM: 16
first row shown: Archived task #2498 done 2024-01-06