Alexander
bb0895c9b5
Four panel fetches (muscle heatmap, nutrition stats, own periods, shared
periods) are now returned as unawaited promises from load() and resolved
into $state-backed locals on the client via $effect. The load function
keeps awaiting only stats/goal/latest since the main charts, goal
header, and body-part cards depend on them immediately.
Rationale for the $state-backed resolution rather than {#await}: the
user wants the nutrition card shells and the muscle heatmap container
to render their skeleton shape on first paint and only fill in the
numbers once the data arrives. Defaults (`{}`, empty heatmap, `[]`)
match the previous error-fallback shapes so the existing `!= null`
checks inside each card cascade naturally to the "—" branches while
the promise is in flight. No template restructuring beyond dropping
the outer `{#if ns}` (which already hid everything when null).
stats (overview) is intentionally still awaited: it feeds ~30 $derived
chart expressions and wrapping it would mean recreating every Chart.js
instance after the promise settles.
3.8 KiB
TODO
Perf (audit 2026-04-23)
Order = impact. Font items + app.html preload intentionally skipped.
- 1. Lucide subpath imports — convert
from '@lucide/svelte'barrel imports to@lucide/svelte/icons/<kebab-name>so Vite tree-shakes per-icon (current 748 KB shared chunk) - 2. Chart.js dynamic import in
FitnessChart.svelte(drop 244 KB from non-stats fitness routes) - 3. Recipe API endpoints — drop
JSON.parse(JSON.stringify(...))double-serialize (9 endpoints). Client-side shuffle / cache headers deferred (would require rethinking hero preload + hydration) - 4. Favorites page — drop unnecessary
all_brieffetch (verified Search usesfavoritesOnlysoallRecipeswas redundant) - 5. Replace redundant
locals.auth()withlocals.sessionacross all routes (68 files, 107 sites — loaders, actions, API endpoints) - 6. Stream fitness stats loader — muscleHeatmap, nutritionStats, periods, sharedPeriods now stream via
{#await}.statsstill awaited (too many chart $deriveds depend on it) - 7. Overview endpoint — add
.select(...)projection, cap timeseries window - 8. Calendar payload trim — drop
namefromyearDays, pre-filterfeastDotsserver-side - 9. History sessions endpoint — slim exercise payload for list view
- 10.
Cache-Controlheaders on stable API endpoints (all_brief, calendar, exercises metadata) - 11. Search — debounce 200 ms + server-side pre-normalized
_searchKey
Features
[x] on /fitness/measure, fill "Past measurements" in SSR only for the last 10 measurements. anything further should be fetched client side on mount to decreae initial page load time. use a "show more" button and paginate measurments. [x] on /fitness/measure (resp. their associated logging API routes), consolidate measurements by day. If we want to log another measurement, overwriting an old one, show a warning to indicate this. disparate measurements (e.g., weight and bodyfat) should not show this warning but simply be merged into one log entry for that day. [x] on /fitness/measure in the past measurments tab, show more than "Body measurements only" if we don't have Bodyweight logged. we can be a bit more elaborate in our syntax here tbh. [x] add a button on /fitness/measure/body-parts for each measurement directly below to say "Same value", instead of having to hit +, then - to lock in same number [x] BF graph (with trend line like weight graph) on /fitness/stats page. Emphasize relative changes, not absolute numbers in design (as we cannot trust those) (e.g., use start day of overview as 0% and then show +/- x % on the graph) [x] Workshop better names than "Measure" for the /fitness/measure route. It's about body data points (i.e., non-food related). What's a better, short name than "Measure" to capture the logging of weight, body composition, body part measurements, and period tracking? [x] on /fitness/stats/histoy/ for body measurement graphs, make the range reasonable. e.g., if we have 1 cm change, do not fill the entire y-height with 1 cm. Use reasonable padding for low ranges (i think we do something like htis already on the weight graph?) [ ] Make the Period ended button a lot more prominent [ ] swap heart emoji on recipe favorites to lucide icon [ ] coop and migros cards on shopping list for scanning [ ] login icon from lucide in header
Refactor Recipe Search Component
Refactor src/lib/components/Search.svelte to use the new SearchInput.svelte component for the visual input part. This will:
- Reduce code duplication between recipe search and prayer search
- Keep the visual styling consistent across the site
- Separate concerns: SearchInput handles the UI, Search.svelte handles recipe-specific filtering logic
Files involved:
src/lib/components/Search.svelte- refactor to use SearchInputsrc/lib/components/SearchInput.svelte- the reusable input component