feat: parent dashboard shows player team schedule #218
No reviewers
Labels
No labels
domain:backend
domain:devops
domain:frontend
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ldraney/westside-app!218
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "214-parent-dashboard-schedule"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Replaces the placeholder text "Schedule data will appear here once practice times are confirmed" on the parent dashboard (
/my-players) with a functional schedule display. Fetches/account/players(withteam_idsfrom basketball-api#334) and/public/schedulein parallel, filters practices and events by each player's team_ids, and groups the display by player name then by team.Changes
src/routes/(app)/my-players/+page.svelte— AddedpublicFetchimport, schedule state variables,buildPlayerSchedules()grouping logic, time/date formatting helpers, and replaced the placeholder section with practice cards (green left border) and event cards (blue left border) grouped per player per team. Scoped CSS for the schedule components using the existing design system variables.Test Plan
svelte-checkpasses with 0 errors (7 pre-existing warnings, none in modified file)vite buildsucceeds?mock=offered) still works with team_ids added to mock dataReview Checklist
svelte-checkpasses with 0 errorsvite buildsucceedsRelated
team_idstoAccountPlayerResponse— merged)Related Notes
PR #218 Review
DOMAIN REVIEW
Stack: SvelteKit / Svelte 5 ($state/$derived runes) / Pure CSS vars
Architecture: Single-file change to
src/routes/(app)/my-players/+page.svelte(+363/-11). Adds schedule fetching viapublicFetch, client-side filtering/grouping by player->team, and schedule card rendering with scoped CSS.What works well:
Promise.allSettledfor parallel fetching with independent error handling -- good resilience pattern$derivedforplayerSchedules-- reactive recomputation when state changes, idiomatic Svelte 5team_idis well-thought-out with dedup guard (!existing.events.some(...))--space-*,--color-*,--border-radius) with no TailwindformatTimehandles edge cases: null/undefined input, already-formatted AM/PM strings, midnight (h=0 -> 12 AM)Concerns:
DRY violation across sibling PR #217: The following functions are copy-pasted nearly verbatim between this PR and PR #217 (coach dashboard):
DAY_NAMESconstantformatTime()-- identical logicdayName()-- identical logicformatDate()-- nearly identical (only difference: parent includesweekday: 'short'in locale options)formatDateRange()-- nearly identical (parent uses en-dash, coach uses hyphen)sortEventsByDate()-- identical logicThese should be extracted to a shared
$lib/schedule-utils.jsmodule. Six duplicated functions across two files is a maintenance divergence risk. However, this is not in an auth/security path, so it does not meet the BLOCKER threshold for DRY. It is a strong nit that should be tracked as a follow-up issue.Double sort in template:
sortPracticesByDay(team.practices)andsortEventsByDate(team.events)are called directly in{#each}blocks. These will re-execute on every render cycle. Consider pre-sorting insidebuildPlayerSchedulesor using$derivedwrappers. Not a blocker for a dashboard page with small data sets, but worth noting.margin-top: 1pxandmargin-top: 2pxmagic numbers: Lines in.parent-schedule-event-date,.parent-schedule-location, and.parent-schedule-notesuse pixel values instead of spacing tokens. Minor inconsistency with the otherwise clean token usage.Accessibility: Schedule cards lack ARIA semantics. Practice and event cards are purely visual
<div>elements. Considerrole="list"on.parent-schedule-cardsandrole="listitem"on each card for screen reader navigation. The color-coded left borders (green vs blue) carry meaning without a text-based alternative for colorblind users -- the "Practice" / "Events" sub-labels mitigate this, but addingaria-labelon cards would strengthen it.formatDatetimezone nuance:new Date(dateStr + 'T00:00:00')creates a local-timezone date, which is correct for display purposes. Just noting this is intentional and works because all dates are local basketball schedule dates.BLOCKERS
None. No unvalidated user input (data comes from authenticated API and public API, rendered as text content not innerHTML). No secrets. No auth/security path duplication. Test plan documented and builds pass per PR body.
Note on test coverage: This is a pure frontend SvelteKit page with no unit tests. The westside-landing repo appears to not have a test infrastructure (no test runner configured). Per the repo's conventions,
svelte-checkandvite buildpassing constitutes the test gate. The helper functions (formatTime,dayName,buildPlayerSchedules) would benefit from unit tests, but this is a repo-level gap, not a PR-level blocker.NITS
Extract shared schedule utilities:
DAY_NAMES,formatTime,dayName,formatDate,formatDateRange,sortEventsByDateare duplicated with PR #217. Extract to$lib/schedule-utils.js. Track as a follow-up issue.Pre-sort instead of sort-in-template: Move
sortPracticesByDayandsortEventsByDateintobuildPlayerSchedulesto avoid re-sorting on each render.Replace magic pixel values:
margin-top: 1pxandmargin-top: 2pxin schedule card styles should usevar(--space-xs)or a smaller token for consistency.Minor en-dash inconsistency: PR #218 uses
\u2013(en-dash) informatDateRange, while PR #217 uses-(hyphen). Extracting to shared utils would fix this naturally.Accessibility: Add
role="list"/role="listitem"to schedule card containers. Consideraria-labelon cards summarizing the schedule item for screen readers.SOP COMPLIANCE
214-parent-dashboard-schedulematches issue #214story:labels only in sibling PR #217, not in this one. Minor gap.svelte-checkandvite buildpass per PR bodyPROCESS OBSERVATIONS
Promise.allSettledmeans schedule failure does not break player loading. Graceful degradation built in.$lib/schedule-utils.jsextraction before more dashboard pages adopt the same pattern.VERDICT: APPROVED
Clean, well-structured implementation. No blockers. The DRY concern across sibling PRs is real but non-blocking -- track as a follow-up issue for shared utility extraction before the pattern spreads further.
6c43fe9850571dbc5835