# Customer · Discover — UI / Screens

**Scope flag (important):** The Discover UI is a **mobile customer-app** screen
(`portals/customer/Discover.tsx`). Our customer-facing client is the **mobile app**,
which is a separate repo and consumes this Yii app only as an **API**. There is **no
matching view** in `frontend/` (shop portal) or `backend/` (admin) — and there
should not be. UI parity therefore cannot be satisfied inside this repo; what we own
is the **data the screen needs**, served by the API. UI gaps below are recorded as
"mobile-app scope / not in this repo".

---

## Demo screen anatomy (`Discover.tsx`)

| Region | Demo lines | Description |
|---|---|---|
| Brand header | `:31-48` | Gradient `brand-700→600`, location pill "Riyadh, SA", avatar initials, H1 "Find your next look", search input |
| Search box | `:42-48` | Decorative (no filter wired in demo) |
| Tabs | `:50-63` | Segmented "discover" / "deals", active = white pill |
| Discover body | `:68-86` | "Salons near you" + "N open" count, list of `ShopCard` |
| ShopCard | `:117-172` | Cover gradient (logoHue), rating badge, avatar tile, name, type·reviews, distance/services/min-price row, "Book now" button |
| Deals body | `:88-110` | "Deals for you", per-deal row: icon (Tag / Sparkles for platform), description, shop name, chevron |

### States
- **Empty:** no explicit empty state — empty `shops`/`deals` just renders header +
  zero rows (count shows `0 open`).
- **Error:** none (in-memory store, cannot fail).
- **RTL:** demo is global LTR/RTL via i18n; this screen uses flex utilities that
  flip under `dir="rtl"`. Strings here are hard-coded English ("Find your next look",
  "Salons near you", "Book now", "open", type labels) — **not** routed through i18n on
  this screen, so the demo screen itself is effectively English-only.
- **Book now:** toast stub (`:79`) — flow not built.

---

## Our side

- **No Yii view.** `frontend/` is the shop portal (aurora reskin); `backend/` is
  admin. Neither contains a customer Discover screen — correct, since the customer
  surface is the mobile app.
- **API payload as the contract:** `api/resources/ShopsResource.php` supplies the
  card data (`title`, `rate`, `image`, `distance`, `open_at/close_at`, `is_overnight`,
  `shop_category*`, `service_categories`, `location`, `status`, …). This is **richer**
  than the demo card needs.

### Concrete UI-data gaps (what the mobile app would be missing from our API)
1. **Per-shop service count + min price** are not aggregated on the shop list item
   (`ShopsResource` has no `services_count` / `from_price`). Demo computes these
   client-side from the full service set; our mobile app would need a second call or
   new aggregate fields. → **gap**.
2. **Gender/type display label** ("Women/Men/Unisex") not exposed as a ready string;
   only the raw `gender` underlies filtering. → minor gap.
3. **Deals feed**: no structured deals payload (see business.md / parity.md). Ads
   endpoint returns banner images only (`AdsResource.php`). → **gap**.
4. **logoHue / generated-avatar tint**: N/A — we serve real `image`; not a defect.
5. **i18n**: our API already returns Arabic via `?lang=ar` (e.g. `AdsController.php:21`);
   the demo screen hard-codes English. Ours is ahead on localisation.

### Things the API has that the demo screen does not use
- Real ratings + `total_rates`, real Haversine distance, search by name, category
  filter, popular/top-rated flags, city filter, pagination, overnight-hours display.
  These exceed the current Discover screen and support a fuller search experience.