--- title: "Understand favorite states" description: "Distinguish favorite relation, local icon, list, navigation, analytics, and reorder states." canonical: https://docs.ordering.co/docs/products/customer-app/browse/favorites/ --- # Understand favorite states Customer App can conditionally present favorite Products, Businesses, and Orders for a signed-in account. A highlighted icon, missing card, success toast, or updated list is not an authoritative favorite-operation receipt. > **Important boundary** > > Do not tap a favorite control repeatedly to make the icon or list agree with an expected result. A request, local flag, list removal, analytics event, and later read can settle separately. ## The three tabs have different owners | Tab | Current visible class | What it does not prove | | ---------- | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Businesses | Saved business cards resolved against current location and order context | Business availability, open status, menu eligibility, or current favorite flag | | Products | Saved product cards resolved against current product/business data | Current catalog, inventory, options, price, or cart readiness | | Orders | Saved order cards with current status presentation and possible Reorder handoff | Order ownership, minimal data, reorder safety, cart reconstruction, or payment readiness | The tabs are separate reads and mutation surfaces. A result in one does not authorize or settle another. ## Add, remove, icon, and list state differ Favorite controls can appear on business cards, product cards, Product Details, and order cards. The request direction can depend on the local favorite flag. | State | Safe interpretation | | --------------------------- | ------------------------------------------------------------------------ | | Outline/inactive icon | Local item state does not currently mark the item as favorite | | Filled/active icon | Local state marks it as favorite; server/list freshness remains separate | | Action loading | One controller considers a request pending | | Success toast | One response layer reported success | | Card removed from Favorites | Local list reacted to a remove-like update | | Card remains or returns | Local flag, list read, original resource, or a later response disagrees | | Error | Favorite relation is unresolved; do not repeat automatically | Product Details currently passes its favorite flag into the mutation handler in a way that can invert add and remove intent. Do not use Product Details favorite behavior as confirmation that a favorite was added or removed. ## Loading, empty, and error can converge Direct entry initializes the active tab with a loading state. Each tab can then fetch favorite relations and resolve the corresponding original resources. The visible list shows loading placeholders and a generic empty state, but a controller error with no rows can look like an ordinary empty list. An empty tab therefore does not prove that the account has no favorites, that a remove succeeded, or that a product, business, or order no longer exists. It also must not disclose whether a foreign resource exists. ## Query, filtering, and original-resource boundaries Favorite relation reads and original resource reads are separate. Conditional location, franchise, order-type, and resource filters can be applied before cards are resolved. One conditional query branch can include a malformed prefix, and returned relation rows can lack a reliable favorite flag after the original resource is resolved. A Favorite card must remain bound to the current account, project, session, resource type, resource owner, and revision. Missing or malformed filters must fail closed; they must not broaden a list, reveal another account's resource, or silently convert an error into empty state. ## Card navigation is a handoff | Card/action | Handoff | Boundary | | ---------------------- | --------------------- | -------------------------------------------------------------------------------------------- | | Favorite business body | Business page | Current menu, location, fulfillment, open state, and availability are re-evaluated | | Favorite product body | Product Details | Current product, business, category, options, inventory, and favorite state are re-evaluated | | Favorite order card | Order presentation | Current account/order authorization and minimal projection remain required | | Reorder | Reorder/cart workflow | Destructive existing-cart decisions and reconstruction settle separately | Card body navigation is not a favorite add/remove action, and navigation does not prove the destination is authorized, current, or ready for cart mutation. ## Rapid taps, duplicate work, and analytics Favorite controllers maintain local loading state, but one server-side idempotency or uniqueness receipt and complete rapid-tap suppression are not established across every surface. Duplicate, reordered, or lost responses can leave the icon, card list, and relation state inconsistent. Some product-favorite actions emit wishlist analytics after a successful response. Analytics is a separate purpose and effect. It must not include sensitive product, order, customer, or inference context without a valid purpose, consent, and data-minimization basis, and it is not proof that the favorite state persisted. ## Favorite Orders require stronger authorization Favorite-order relations must be limited to orders owned by the current authorized account and returned through a purpose-minimal projection. A favorite relation or order reference is not capability to read another customer's order, products, address, payment, student, gift, message, location, or provider state. The current Favorite Orders path also exposes a Reorder handoff. Reorder can replace existing carts and rebuild products through a separate destructive, multi-stage process. Favorite status does not prove reorder eligibility, fidelity, complete cart reconstruction, Checkout readiness, or success. ## Unknown outcomes and safe troubleshooting | Situation | Safe response | | -------------------------------------------- | --------------------------------------------------------------------------- | | Icon and list disagree | Treat favorite settlement as unknown; do not tap again | | Success toast but card remains | Preserve the mismatch without refreshing as a test | | Empty state appears after an error | Do not infer successful removal or resource absence | | Product Details behaves opposite to the icon | Stop; the current action direction is unsafe | | Business card opens but is unavailable | Treat navigation and business readiness separately | | Favorite order is missing or too detailed | Treat ownership/projection as unresolved and do not use Reorder | | Reorder opens or returns unexpectedly | Keep cart/order outcome unknown; do not continue to Checkout or payment | | Account or project changed | Reject prior lists, icons, requests, analytics, order and reorder callbacks | Support reports should use only a value-free state class such as “favorite state unresolved.” Do not include favorite contents, product/business/order or customer details, account/order/cart identifiers, analytics payloads, links, or private screenshots. ## Privacy and accessibility - Favorite businesses, products, orders, and inferred interests can reveal private behavior. Keep them out of documentation, diagnostics, analytics, and support evidence unless a valid purpose requires them. - Tabs need selected state and scope; lists need loading, empty, error, stale, pagination, and unknown semantics. - Favorite controls need accessible names, current state, busy/disabled state, add/remove intent, and completion/error announcements. - Card-body navigation and favorite controls need distinct names and focus targets. Reorder must be identified as a separate destructive cart handoff. - At large text sizes, cards, status, errors, and actions should reflow without hiding the favorite or Reorder boundary. Screen-reader, keyboard, switch, safe-area, Back, and reduced-motion behavior can differ by platform. ## Related guides - [Business page overview](https://docs.ordering.co/docs/products/customer-app/browse/business-page/) - [Customize a product](https://docs.ordering.co/docs/products/customer-app/browse/customize-product/) - [Review your cart before checkout](https://docs.ordering.co/docs/products/customer-app/cart-checkout/) - [Reorder from a previous order](https://docs.ordering.co/docs/products/customer-app/orders-support/reorder/) - [Understand active and past orders](https://docs.ordering.co/docs/products/customer-app/orders-support/) - [Understand privacy and consent](https://docs.ordering.co/docs/products/customer-app/app-behavior/consent/)