Favorites — Domain-Control Data-Gap Analysis

Scoping of the Favorites screens — the "My Favorites" list and its condensed variant. Documentation only.

Figma file R6hPjBdjSIn6946qTJasUC · nodes 5287:15227 (favorites) · 5287:15454 (favorites-list). Source: Figma MCP + codebase (RestService — thorough) · Branch docs/set-5287-data-gap.

Favorites (5287:15227)

Favorites — list (5287:15454)

1 · Screens & controls

• Favorites (5287:15227) — title "Favorites"; the member's favorited items rendered by their native control: a card-lg (favorited document/content), a card-sm (favorited nav tile, e.g. DART), a card-btn (favorited button, e.g. Committees). Heterogeneous list.
• Favorites — list (5287:15454) — the same favorites as a condensed Master Form Field row list (title + » → item).

2 · Data-source mapping

3 · Gap & refinement to Change 3

This set confirms and refines the Favorites capability ask:

• Heterogeneous by design — a favorite can be a document (card-lg), a nav tile (card-sm), or a button (card-btn). So the favorites store keys on (itemType, itemId), exactly as proposed.
• Read must support rendering — the Favorites screen has to draw each item with its native control, so the favorites read either (a) returns enough to hydrate each item, or (b) returns (itemType, itemId) and the client hydrates from the per-type sources (DocumentItem, MenuItem, …). Confirm which approach (hydrated payload vs ID-only + client hydrate).
• Two presentations, one source — the rich view and the condensed list bind the same favorites set.
• Ordering / unfavorite — confirm an order field and the toggle-off path (the heart elsewhere adds; this screen removes).

4 · Summary

• Backend gap: Favorites capability (Required API Change 3) — read + toggle, keyed on (itemType, itemId). This feature is blocked on it.
• Confirm: hydrated payload vs ID-only read · ordering field.
• Presentation: reuses existing controls (card-lg · card-sm · card-btn · Master Form Field row) — no new scaffolds.

Tracked in screen-mapping.html; backend ask in backend-api-mapping-report.html §5 Change 3.

5 · Resolution (2026-07-08)

• Hydrated vs ID-only (§3 open question) — resolved: ID-only + client hydrate. The delivered GetFavorites response returns id/userId/itemTypeId/itemTypeDescription/itemId/sortOrder/title/ audit fields only — not a hydrated payload. The client (FavoritesViewModel.HydrateAsync) joins itemId against IDocumentsQueries/IMenuQueries to build the card-lg/card-sm view models.
• Ordering (§3 open question) — resolved. sortOrder is a real field on the delivered Favorite record.
• Item types — confirmed, no "button" type. The delivered contract has exactly three item types: 1=Menu Item, 2=Document Item, 3=Notification Center Message. There is no distinct backend "button" type — card-btn vs card-sm for a Menu Item favorite is a Figma-curated presentation choice, not data-driven; v1 renders all Menu Item favorites as card-sm uniformly (flagged as a follow-up once a concrete signal exists to key the split off of). (Extended 2026-07-16: type 4=Document Category added client-first — D62, backend handoff Task AB#2271; raw id {scope}|{categoryKey}, hydrated from the GetDocuments tree. The live API must accept type 4 before the mock→live flip. The wire ItemId convention is now codified as FavoriteKey's composite {typePrefix}-{rawId} — menu-/doc-/ msg-/cat-, matching the backend's production rows; parsing splits on the first dash only (GUID raw ids contain dashes) and legacy un-prefixed values pass through unchanged, degrading to a failed lookup rather than a crash.)
• Unfavorite/remove — implemented. RemoveFavoriteAsync(itemTypeId, itemId); the heart on the Favorites screen itself is the remove control (no separate confirm step), matching "this screen removes."
• Heterogeneous rendering — implemented via HeroCard (Document → card-lg) and CardSmall (Menu Item → card-sm); Notification Center Message favorites render as a title-only row (no card component exists for that type). The condensed Master Form Field list view (5287:15454) was not built in this pass — only the rich view shipped.
• New: item-unavailable fallback. Not anticipated by the original gap analysis — if a favorited item's backing content no longer resolves (deleted document, removed menu item), the row still renders (title-only, from the favorite record) but routes to Off the Radar on tap instead of a dead link.
• New: favoriting is auth-gated end-to-end. The heart affordance across the card library (Card/CardSmall/HeroCard/ButtonCard) only renders when IAuthentication.IsLoggedIn — not shown-disabled, genuinely absent from the DOM when logged out — and /favorites itself redirects to /login if visited unauthenticated.
• Tester Walkthrough available. See the Favorites Tester Walkthrough for a screenshot-illustrated, scenario-by-scenario smoke test covering the full add/view/remove/dead-link loop.
• Live-validation status (2026-07-09). Walkthrough executed end-to-end on the iOS simulator. Confirmed in mock mode: auth-gated heart rendering (zero heart elements in the DOM logged out), /favorites → /login redirect, document-favorite add / persist / remove, empty state, and the Off the Radar page (route, blank-fill copy, back-to-/favorites chevron). Live mode is not yet exercisable: GET /v2/api/mobilecontent/favorites (and …/itemtypes, POST) return 404 on the production gateway — the MobileMenu.ApiClient 1.0.7 package is delivered but the service isn't reachable there yet, and the resulting ApiException propagates unhandled out of FavoriteToggleContext.LoadAsync, killing the Home Preview page (hardening fix queued). Also found: menu-item hearts silently no-op when the rendered menu items carry no SpecialCode (offline-fallback menu list; fixed same day). Later that day Home Preview's menu quick-list rows were replaced by document category rows (2026-07-09 direction) — menu-item favorites still render on the Favorites screen, but the app currently has no surface to add one; the walkthrough's Check 4 is parked until a screen with saveable menu items ships.