A screen is a view of what is true
In the reading-list app, the current filter, the saved books, and the form contents all affect what appears. Those are different kinds of state. The filter can change without changing a book. A typed title is a draft until saving succeeds. Thinking about these separately makes errors easier to find and interactions easier to explain.
Describe one record before designing ten screens
Our book record has an ID, title, author, note, and status. The ID identifies one record even if its status changes. The title is required. Author and note are optional. Status is either “want” or “done.” These small rules establish which states are valid and what the interface must communicate.
Try writing three fictional records by hand, including one with a long title and one with no author. If your card layout cannot accommodate them, the issue is a design assumption you can resolve before adding a backend.
Follow the data through one action
- The user submits the form.
- The program trims and checks the title.
- It checks the title-and-author duplicate rule.
- It adds a valid record to the working list.
- It attempts to persist the list and redraws the interface.
- It reports success or explains that saving is unavailable.
Each boundary is a debugging opportunity. If a book appears but disappears on reload, investigate persistence. If a finished book is hidden, inspect the selected filter before assuming the record was deleted. Ask your AI partner to identify which boundary failed and what evidence supports that explanation.
Local does not mean cloud
Browser local storage belongs to a site’s origin and normally persists across sessions. It is not cross-device synchronization, and private browsing or clearing browser data can remove it. Our learning tools keep their records locally and provide exports. A different domain will have a different store. See MDN’s Web Storage reference.
When does an API enter the picture?
An API is an interface through which software requests a service or data. A book-search API might accept a query and return matching records. Your design then needs loading, no results, network failure, and service-limit states. Decide what happens when the service is unavailable before making it central to the task.
You do not need an API just to filter a small list already in the browser. Add a connection when the user benefit requires it. Keep secret credentials off the client; a browser-delivered script can be inspected. Before using a service, check its documentation, allowed usage, limits, and data handling.
Your next exercise
Open the working reference. Save one fictional book, change its status, filter, and reload. In your Passport, explain which action changed the record, which changed only the view, and where the data survives. Then write one requirement for a future shared version and what new failure it introduces.