Repository navigation
Frontend: Greek taverna theme, real order history, live-update explanation - #13
Open
devinder-dev wants to merge 4 commits into
Open
devinder-dev wants to merge 4 commits into
devinder-dev wants to merge 4 commits into
Conversation
…explanation
Reseeds the menu with Greek dishes (Gyros, Souvlaki, Greek Salad,
Moussaka) instead of placeholder pizza, and redesigns the frontend around
a Mediterranean color palette with food-emoji menu cards instead of a
plain list.
Order history now stores a snapshot of what was actually submitted
(items + total, captured at placement time from the same cart lines sent
to POST /api/orders) instead of just a bare order id, so the history page
shows "2x Gyros, 1x Greek Salad - $31.00" rather than a raw UUID.
The order status screen now explains how the live update actually works
("checking every 1.5s" while polling, "the kitchen service published an
event over RabbitMQ" once ready) instead of just showing a stage tracker
with no explanation of the mechanism.
…torage
A browser that already had order-history entries from before items/
totalCents were added to the stored shape would crash OrderHistoryPage:
entry.items.map(...) throws on the old {orderId, placedAt}-only shape, and
with no error boundary, that unmounts the whole app to a blank page. This
actually happened during manual testing, not hypothetically.
Fixes:
- getOrderHistory now validates each entry's actual shape and silently
drops anything that doesn't match, instead of trusting raw JSON.
- Added a top-level React error boundary as a backstop for any other
unexpected render error, so a future bug shows a recoverable message
instead of a blank page.
- order-events.ts now logs a success line when it syncs an order's status
from a kitchen event, matching every other consumer in the system
(kitchen, notification) — it was the only one with no visible
confirmation that it had actually run.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to the merged frontend PR (#12), addressing feedback that the UI looked too basic, the order history was unreadable, and a real bug found while clicking through: opening /history with old localStorage data crashed to a blank page.
entry.items.map(...)onitems: undefined), and with no error boundary, that blanked the whole app.getOrderHistorynow validates each entry's shape and drops anything malformed; added a top-level error boundary as a backstop for any future unexpected render error.order-events.ts(order service's own consumer of kitchen's events) now logs a success line, matching every other consumer in the system (kitchen, notification) - it was the only one with no visible confirmation it had actually run.Full verification pass (not just unit tests)
bun run typecheckclean across all 7 packagesbun run testgreen - 60 tests total (43 frontend, including the new error-boundary and old-shape-localStorage regression tests)order.placedevent (same eventId) twice directly to RabbitMQ - kitchen's log shows "accepted" and "ready" exactly once each, proving the Redis-backed dedupe actually collapses a real redelivery