james
104737e4e1
Wave 4 of replacing the fixed-data mock adapter, and the first capability the
mall never had a backend for: the home page's banners, promo tiles, quick links
and floor advert art move out of local arrays.
- four explicit tables (`banners`, `promos`, `quick_links`, `floor_adverts`)
rather than one JSONB payload table, so Postgres enforces each shape
- a migration seeds them from the assets the page already rendered, so the flip
is visually a no-op. Destinations are real routes now: the mock's promo links
pointed at dangling `?category=c1` ids and its first banner used `sort=sales`,
which the catalog API rejects
- `GET /api/content/home` is public and returns the four active, ordered lists,
always including a key so a page can render a missing block
- `GET /api/admin/content` and `PUT /api/admin/content/{kind}` let a platform
admin read everything and replace one kind transactionally, with positions
reindexed from the submitted order and a rejected list changing nothing
- the mall's fixed-data adapter learns `getHomeContent`, and a `content` domain
joins the per-domain switch so the rollback path still renders the page
Verified: 23 backend tests green including six new content tests; all three
frontends build; the home page renders the same four blocks as before, an admin
reorder and deactivation change the rendered carousel, and the fixed-data
rollback renders every block with the backend stopped.
OpenSpec change: openspec/changes/replace-mock-api-wave-4
32 lines
2.0 KiB
Markdown
32 lines
2.0 KiB
Markdown
# Proposal
|
|
|
|
## Why
|
|
|
|
Every domain that had an API is now live, but the home page still renders from `~/mock/data`: the carousel, promotion tiles, quick-link strip and floor advert art are local arrays. They are the last thing between the storefront and backend-driven content, and nobody can change them without a deploy.
|
|
|
|
## What Changes
|
|
|
|
- Add four content kinds behind one public read: `GET /api/content/home` returns banners, promos, quick links and floor advert art, ordered and active-only.
|
|
- Store them in typed tables rather than one JSONB blob, so the database enforces each shape.
|
|
- Seed them from the assets the page already uses (`banner-1..3`, `promo-1..3`, `floor-adv-1..6`), so the home page looks unchanged while becoming data-driven.
|
|
- Manage them with a small admin surface: `GET /api/admin/content` plus `PUT /api/admin/content/{kind}`, replacing one ordered list transactionally. Ordering falls out of array order, and four lists do not need twelve endpoints.
|
|
- Point `pages/index.vue` at the content API and delete the three mock arrays. The quick-link glyph stays in the row: it is a short SVG path, so a new link renders without a frontend deploy.
|
|
|
|
## Capabilities
|
|
|
|
### New Capabilities
|
|
|
|
- `storefront-content`: the storefront's editable marketing content — home banners, promotion tiles, quick links and floor advert art — read publicly and written by platform admins.
|
|
|
|
### Modified Capabilities
|
|
|
|
- `frontend-mall`: the home page sources its banner, promotion, quick-link and floor advert content from the content API instead of local constants.
|
|
|
|
## Impact
|
|
|
|
A new migration and `apps/api/src/routes/` module; `packages/shared/src/{api,types}.ts`; `apps/mall/pages/index.vue`. The shared contract change means all three frontends rebuild.
|
|
|
|
## Non-goals
|
|
|
|
No image upload: rows reference URLs, seeded with the existing `/mock/*.svg` assets. No content for the seckill, collective or integral pages, and none for stores, brands, coupons, favourites or addresses — each stays mock until its own wave. No scheduling, A/B testing or translated artwork.
|