Empty State

The building block under both a genuinely empty result ("no rows match") and, via ErrorState, a failed one. Keeping them as one shape (icon + title + description + action) means a screen only ever has two non-data states to design for, not a bespoke one per component.

Props

Implementation notes

• An empty result is not an error. If a query legitimately returns zero rows (a filter that matches nothing, a fresh account with no history yet), that's EmptyState — reserve ErrorState for when the fetch itself failed. Conflating the two teaches users to distrust "no results" messages, wondering if something actually broke.
• The action slot is for recovery, not navigation. "Clear filters" or "Create the first one" belongs here; a generic "Go to dashboard" link usually means the empty state is being used to paper over a flow problem rather than describe a real, expected zero-result state.
• A filtered empty result and an unfiltered one are different facts. With filters applied, the user narrowed a real set down to nothing and widening one is the way back. With none applied, the request was for everything and the server answered with nothing — there is no filter to widen, and naming one as the remedy describes a screen the reader is not looking at. Branch the copy on the filters, and withhold a "Clear filters" action where there is nothing to clear. The same rule governs a Combobox with no options; see Combobox → States.

Do / Don't

• Do write the title in terms of what the user did ("No seasons match") when the user did something — a filter, a search — rather than the system's internals ("Query returned 0 rows").
• Do say the request returned nothing ("No price seasons were returned") when no filter was applied, because then the user did nothing that could have caused it.
• Don't reach for EmptyState when a fetch is still loading — that's a skeleton or spinner state, not an empty one; showing "nothing found" while still loading reads as a false negative.