Understand business discovery states
Business discovery can present businesses after Customer App has a session and selected ordering context. A visible list is a returned presentation, not proof that every business, fee, estimate, schedule, product, or cart action is current or eligible.
Address, order type, ordering moment, account, project, connectivity, and returned data can settle separately. When these layers disagree, keep discovery stale or unknown rather than issuing another consequential action.
Ordering context and presentation
The header can present an address, cart entry, order type, ordering moment, and map handoff. Each is a separate state owner. Changing one can make previously shown business results stale before a replacement list settles.
| State | Safe interpretation |
|---|---|
| No selected location | Business discovery is not established. |
| Context visible | Address/type/moment presentation exists; authorization and freshness remain separate. |
| Context changing | Previously shown businesses and estimates can be stale. |
| Cart badge | Local/cart quantity presentation only; no checkout readiness. |
| Map handoff | Navigation intent only; map/provider state is separate. |
Independent discovery sections
Depending on returned data and presentation configuration, the screen can show a promotional banner, sponsored businesses, business-type controls, a main business list, and, for a signed-in customer, an optional order-progress preview. These sections settle independently. One missing section does not prove the entire discovery read failed.
An order preview is a passive, minimal handoff state for a signed-in customer. Its status or estimated time does not prove order freshness, tracking, or delivery settlement.
Business card states
A standard card can present a name, imagery or placeholder, optional logo, returned review count, open/closed state, fulfillment estimate, fee, distance, a Favorite control, discount, ribbon, or preorder label. Optional fields can differ.
A sponsored card is compact and can present its name and returned review count. It does not present a logo, a Favorite control, or distance.
Favorite is a separate mutating journey. Seeing a Favorite control does not establish that a business was saved.
The displayed review number is a returned count on this surface, not an average rating. Remote images, card text, schedule state, fees, estimates, and list position can settle separately. Favorite state belongs to its own journey and is not determined by the card alone.
Open, closed, and preorder handoffs
| Card state | Safe boundary |
|---|---|
| Open business | A business-page handoff can be available; destination data and actions remain separately owned. |
| Closed business | The card can remain inert and show closed feedback. |
| Preorder label | A scheduling handoff can be available; no valid candidate or reservation is guaranteed. |
| Order preview | For a signed-in customer, an Order Details handoff can be available; navigation does not change or reconcile the order. |
No business-card handoff adds a product, changes a cart, or places an order.
Loading, pagination, empty, error, and stale states
| State | Safe interpretation |
|---|---|
| Initial loading | Placeholder presentation; request result remains pending. |
| Additional-page loading | Existing and incoming pages can have different freshness. |
| Empty | No businesses are displayed for the current returned state. |
| Error/empty convergence | The interface may not distinguish the cause; nonexistence is unproved. |
| Retained prior rows | Their current authorization and freshness are unknown. |
| Context changed during work | Late results belong to an older generation and must not become current. |
Do not use repeated refreshes to diagnose an unknown result. Use only value-free states such as “business discovery stale” or “business list unresolved.”
Privacy, providers, and accessibility
Device-location warnings, maps, banners, remote media, analytics, sockets, and order previews are separate effect and privacy boundaries. A warning or provider result does not change the selected address by itself.
Business cards, section headings, loading/error/empty states, horizontal controls, closed/preorder feedback, order previews, focus order, large text, screen-reader semantics, reduced motion, and platform Back require independent current-platform verification.
Safe troubleshooting
- If the ordering context changed, keep the prior list stale until current state reconciles.
- If empty and error are indistinguishable, keep the cause unknown.
- If an optional section or card detail is absent, do not infer main-list failure.
- If a handoff does not settle, use only an already-present verified in-app return control; do not repeat a product, cart, order, or provider effect.
- Support reports must contain only a value-free state class, never project, timing, address, order-type, business, account, device, or provider details.
Related guides: Understand business search and filter states · Explore businesses on a map · Choose order type and time · Understand favorite states · View active and past orders · Understand order details and status