s.esmaeiliandClaude Opus 5
9fc0886a57
Step 3 of docs/CATALOG-PAGINATION-PLAN.md. Step 2 added the targeted routes; these are the five callers that were fetching all ~16k products to find a handful of rows: product screen whole catalogue, then find(id) -> GET /products/:id cart re-sync whole catalogue for 2-3 lines -> ?ids= favourites whole catalogue, filtered here -> ?ids= home categories categories derived from it -> /products/facets order row labels joined on variantId -> included with the order Three of these were not merely slow, they were going to be wrong. Favourites filtered the loaded catalogue, so once the list pages a favourite outside the loaded slice silently disappears. Home categories were derived the same way, so a category whose products all sit further down would vanish from the home screen. Order rows looked their title up in the catalogue, which ALREADY failed for a product that had since left the storefront — exactly the old orders history exists for — and rendered a blank row. Order labels went to the server rather than to another id lookup: the item carries productVariantId, not a product id, so ?ids= could not answer it. One nested include in getOrders returns the variant, its product and the product's first image. Deliberately NOT filtered by storefront visibility, so a de-listed product still shows what was bought; asserted in the new spec. OrderItemCard is synchronous now — no fetch, no onMounted, the row renders complete on its first frame. variantLookup is deleted from catalogStore rather than left behind: it existed only to label order rows, and keeping it would have kept a reason to load the full catalogue. getProductsByIds chunks at 100 because the route caps ids there and drops the rest. A partial answer reads to callers as "these products are no longer on the storefront" — the cart would silently drop valid lines. Favourites already run to 874 rows in the imported data (FAV-01). A failed cart re-sync now leaves the cart alone: it is the person's own data in localStorage, and dropping lines because the network blinked is worse than a slightly stale price. The product screen tells a real 404 from a failed request, so only the former renders the not-found page. One bug introduced and caught while doing this: moving the home categories to /facets meant memory.init() no longer loaded the catalogue as a side effect, and the home rails read catalog.products — the home screen would have rendered empty rails. HomeView now loads it explicitly. Found by grepping every caller of configStore.init, which is also how I know HomeView is the only one. Still on the unpaged list by design: the home rails and the search/newest lists. Moving those onto paged reads is step 4, kept separate because it is the risky part — debounce, loading state, and telling "no results" from "still loading". api 334/334 across 30 suites; both apps vue-tsc clean. getOrders has a spec now (3 cases) because its include is a contract both apps depend on and the method had no test at all. Nothing click-tested — the cart re-sync and the favourites screen are the two worth a manual pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
38 lines
1.4 KiB
TypeScript
38 lines
1.4 KiB
TypeScript
// The product and variant titles shown on one line of an order.
|
|
//
|
|
// These now arrive WITH the order: GET customer/me/orders includes each item's
|
|
// variant, its product and the product's first image.
|
|
//
|
|
// Before that, this joined against the shared catalogue in the browser. Two
|
|
// problems, both fixed by the include: it fetched the whole catalogue (~16k
|
|
// products in the real data) to label a few rows, and a product that had since
|
|
// left the storefront was absent from the catalogue, so the row rendered blank —
|
|
// precisely for old orders, which is where order history matters most.
|
|
import type { OrderItemDetail } from '../api/client'
|
|
|
|
export interface VariantLookup {
|
|
productTitle: string
|
|
variantTitle: string
|
|
imageUrl?: string
|
|
}
|
|
|
|
/** Reads the labels off the item itself; no request, no catalogue. */
|
|
export function orderItemLookup(item: OrderItemDetail): VariantLookup | undefined {
|
|
const variant = item.productVariant
|
|
if (!variant) return undefined
|
|
return {
|
|
productTitle: variant.product.title,
|
|
variantTitle: variant.title,
|
|
imageUrl: variant.product.images[0]?.url,
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Kept as a composable so the call sites read unchanged. Synchronous now —
|
|
* `lookup` is resolved from the item, so it returns a value rather than a
|
|
* promise, and callers no longer need to await anything on mount.
|
|
*/
|
|
export function useOrderItemProduct() {
|
|
return { lookup: orderItemLookup }
|
|
}
|