CHAPTER 07 / 13 · READ → DECIDE → BUILD
Build the smallest useful interface.
Connect one task to a clear, accessible result.
Implement the whole state model
Build a task list with loading, empty, error, and loaded states. Add a claim action with idle, pending, confirmed, and conflict behavior. These states should not contradict one another. While a request is pending, communicate progress. If it fails, preserve the user's context and explain whether retrying is safe. Prefer native controls and visible labels to clickable generic elements.
Keep the browser's authority small
The browser can request a claim and display its result. It should not decide whether another person's task can be changed. Pass only the data needed for the interface. Keep credentials and privileged access in the server environment. If your framework supports server-rendered content, avoid shipping all data-fetching and formatting logic to the client merely because one button is interactive.
Inspect beyond the screenshot
Test the board on a narrow viewport and with long titles. Use only the keyboard to reach and activate Claim. Read the loading and conflict messages. Refresh after a successful claim to check persistence. Simulate two requests finishing out of order where the interface supports search or filtering. These checks reveal stale state and focus problems that a static mockup cannot show.
SEE THE DIFFERENCE
A small example. A better decision.
On click, change the task to Claimed immediately and ignore the server response.
Show Claiming while the request is pending. Confirm on success; on conflict, refresh the task and explain that another volunteer claimed it.
You can use optimistic behavior when appropriate, but it needs reconciliation and recovery when the server disagrees.
Your build steps
- Use the vertical-slice prompt with your app flow and API contract.
- Implement loaded, empty, pending, error, and conflict states.
- Test with a keyboard, narrow viewport, and long content.
- Record the final persisted result after refresh, not only the immediate screen.
FROM THE PROMPT LIBRARY
A useful brief for this step.
Implement one complete vertical slice ↗Connects a real user action to a real result without building the whole app.Build a resilient validated form ↗Prevents lost input and confusing submission behavior.Separate server and browser responsibilities ↗Keeps secrets and unnecessary work out of the client bundle.All frontend implementation promptsMAKE THE CALL
Think like the reviewer.
BUILD YOUR WORKBOOK
A working frontend slice
Use the lesson and your project evidence. Your workbook saves privately; keep credentials and private records out. The checks below assess completion of the exercise, not the correctness of an external app.
Before moving on
Loading your workbook…