Final blog post publish

Author: Mortenjenne

content/posts/final-thoughts.md

@@ -85,7 +85,7 @@ The hardest part was discipline. It's tempting to copy-paste styles rather than
 
 The shopping list also uses AI — but differently. Approved ingredient requests from multiple cooks are sent to the backend, normalised and aggregated by AI into a clean consolidated list for the head chef to review. No streaming here — it's a single request and response, but the output quality is meaningfully better than a raw list would be.
 
-**CSS print styles.** The shopping list has a print stylesheet — `@media print` — so the head chef can print a clean, formatted list for the kitchen. It strips navigation, colours, and UI chrome and leaves only the relevant content. I only implemented it on the shopping list, but it showed how much CSS can do that has nothing to do with the screen.
+**JWT validation on startup.** Before the app renders anything, `AuthContext` decodes the stored JWT and checks whether it has expired. If it has, the token and user are cleared immediately — no API call needed, no 401 from the server. It's a small thing, but it reflects a habit worth building: thinking about what can already be wrong before the first request goes out, not just handling errors when they come back.
 
 ---
 
@@ -107,17 +107,15 @@ It also made building more interesting. There's something different about gettin
 
 **A test strategy, early.** There are no automated frontend tests. This is the biggest gap in the project. With a production application, the critical flows — login, suggestion creation, menu publishing — deserve integration tests that run on every deploy. I didn't explore this during the semester, but it's clearly the next thing to understand properly.
 
----
-
-## What didn't make it
+**Token storage tradeoffs.** The JWT is stored in `localStorage`, which persists across browser sessions. During the semester we worked with `localStorage` as the standard approach, but there are tradeoffs worth understanding — `sessionStorage`, `httpOnly` cookies, and in-memory storage each represent different security and UX boundaries. It's an area I'd explore properly on the next project.
 
-Some things were on the list and didn't happen.
+---
 
-**Dark mode.** The design tokens in `:root` are exactly the right foundation for it — swapping a `data-theme` attribute would flip the colour variables. The architecture is ready. I just didn't prioritise it.
+## What comes next
 
-**`sessionStorage` vs `localStorage`.** The JWT is stored in `localStorage`, which persists across browser sessions. `sessionStorage` would clear it when the tab closes — a different security tradeoff worth exploring. I thought about it but left it as-is.
+Takeaway orders — the customer-facing ordering flow — is built but not fully tested. It works in isolation but hasn't been through the same verification as the rest of the system. Single-day menu view is the one feature I ran out of time for. The menu editor shows a full week; during service, staff care about today. The data is already there — it would be a filter, not a structural change.
 
-**Single-day menu view.** The menu editor shows a full week. During service, staff care about today. A day filter would be a rendering change, not a structural one — the data is already there. It's the one thing I'd add first if I came back to this.
+Both are on the list. The codebase stays active after the exam.
 
 ---