Loading, empty, and error are the states most often left unspecified

What it is

Component mocks are almost always drawn against the frame where data is already present and correct, so the cells that go missing are rarely hover — they are loading, empty, and error. The three share a structure: the component currently has no usable content, the canvas has nothing to paint, and the frame drops out of the file.

What is missing is the component’s own appearance and copy slots under those three conditions, not how an empty state should coach a first-run task — that is a delivery-layer problem. The claim here is only that these three cells are the ones a component spec most often omits.

Why it happens

Interactive states are triggered by the pointer and the keyboard; moving the mouse in the design tool is enough to see them. Content states are triggered by the network, the empty set, and a failure callback; a static canvas assumes the data is already there. Lists, cards, pickers, and suggest fields are drawn full first. A spinner, an empty slot, and an error bar need extra frames that do not block the happy-path review, so they slip to “later.”

The three are also misfiled as page problems and kicked out of the component spec: loading is handed to a global skeleton, empty to a blank page, error to a toast. The same picker then loads in a dropdown, sits empty in filter results, and fails after submit, each written locally, while the component as a unit still lacks the three cells. They are not unknown. They simply have no natural trigger on the canvas.

Where it stops holding

A decorative fragment that is always synchronous, locally hardcoded, and unable to fail (a fixed site footer) can omit the trio. “Still appending” on a stream is not first load; a spinner must not replace rows already on screen. Empty-because-forbidden and empty-because-no-matches mean different things; if the component offers a single empty slot, it must at least accept different copy. If errors are required to land in a page-level banner, the component may skip its own error bar, but the spec must say “error is not in this component,” not omit the row as if the case did not exist.

Applying it

• For every component that fetches or submits, add loading, empty, and error as standing rows on the state table, even when a row’s conclusion is “owned by the parent.”
• Give each row real copy slots and dimensions: a skeleton close to the final shape, an empty with a primary sentence, an error with retry or a locator.
• Walk the main path once on a slow network, once with an empty query, once with a forced failure, and confirm the three frames appear rather than flashing blank.
• How to check: open the design file and Storybook. Each of the three rows needs its own story. A row without a story is the commonly missing cell, still missing.

Related

• Same group: R1.03.1 Every component needs a complete interactive state set · R1.03.3 Missing states get improvised during implementation · R1.03.4 Transitions between states fail more often than the states themselves · R1.03.5 Overlapping states need an explicit priority rule · R1.03.6 States must be controllable and observable from outside the component
• Nearby: R2.09 Delivery of empty and content states · R2.05 Completeness of edge-case delivery
• Search terms: missing data-state trio · loading empty error · content state