Wire up the brewery detail route with all new cards, and add the data-requirements handoff doc

This commit is contained in:
Aaron Po
2026-08-28 14:19:07 -04:00
parent 013b4860e1
commit 83863b0bd8
3 changed files with 166 additions and 26 deletions

View File

@@ -0,0 +1,55 @@
# Brewery detail — data requirements
`/breweries/:id` (`app/features/breweries/routes/brewery-detail.tsx`) is built and
live. This document inventories what's real vs. filler, following the same
convention as `BREWERY_INDEX_HANDOFF.md`.
## Status legend
- ✅ **Available** — real data, already wired up.
- ❌ **Missing** — no backend support at all; page currently shows filler or
local-only client state.
## Header, location, dates
| Field | Status | Current source |
| ------------------------------------------- | ------ | ------------------------- |
| Name, description, address, coordinates | ✅ | `GET /api/brewery/{id}` (`BreweryDto`) |
| Created / updated dates | ✅ | `BreweryDto` |
| Founded year, brewery type, website | ❌ | `FILLER_BREWERY_META` — `BreweryPost` has no `FoundedAt`, `Type`, or `Website` column |
## Beers, style breakdown
| Field | Status | Current source | Gap |
| --------------------------- | ------ | --------------------- | -------------------------------------------------------------------------------------- |
| Beers belonging to a brewery | ❌ | `FILLER_BEERS` | `Features.Beers` is an empty stub project — no query/controller exposes `BeerPost` at all, despite the entity already having a `BrewedById` FK. |
| Beer style breakdown | ❌ | Derived client-side from `FILLER_BEERS` | Blocked on the same gap; would otherwise be an aggregate query over a brewery's beers. |
## Likes, ratings, comments
| Field | Status | Current source | Gap |
| ------------------------------ | ------ | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Brewery like/unlike + count | ❌ | Local component state only | No like concept exists anywhere in the schema. Needs a new join table (composite `BreweryPostId`/`UserAccountId`, similar shape to `UserFollow`). |
| Your rating (1–5) + average | ❌ | Local component state only | No brewery rating table/entity/endpoint exists. |
| Comments (list + post) | ❌ | `FILLER_COMMENTS`, local state | No `BreweryPostComment` table exists. `BeerPostComment` is a close schema precedent (comment + 1–5 `CHECK`-constrained rating + FKs) but is itself unused by any code and targets `BeerPost`, not `BreweryPost`. |
| Per-comment like toggle | ❌ | Local component state only | No "like a comment" concept exists anywhere in the schema — would need a new join table alongside a new `BreweryPostComment` table. |
## Summary of backend work to close the gaps
1. Add `FoundedAt`, `Type`, `Website` columns to `BreweryPost` (+ `BreweryDto`).
2. Stand up `Features.Beers`: a query (and controller route) returning a
brewery's beers, following the `Features.Breweries` vertical-slice pattern.
3. New `BreweryPostLike` join table + MediatR command/query + controller
endpoints (toggle, read count/whether current user liked) — public GET,
JWT-required toggle, mirroring `BreweryController`'s
`[AllowAnonymous]`-on-reads pattern.
4. New `BreweryPostRating` table (1–5, `CHECK`-constrained like
`BeerPostComment.Rating`) + aggregate query for average/count.
5. New `BreweryPostComment` table (mirroring `BeerPostComment.sql`, FK'd to
`BreweryPost`) + a new `BreweryPostCommentLike` join table for per-comment
likes, plus the command/query/controller layer for both.
Once these land, swap `FILLER_BEERS` / `FILLER_COMMENTS` / `FILLER_BREWERY_META`
(`utils/filler-brewery-detail.ts`) and the local `useState` in
`brewery-detail.tsx` for loader data and `authorizedRequest`-based mutations
(see `auth.server.ts`).