Skip to content

TODO.md

Latest commit

 

History

History
279 lines (243 loc) · 9.2 KB

TODO.md

File metadata and controls

279 lines (243 loc) · 9.2 KB

ELTTL Availability Tracker - Implementation TODO

Phase 1: Foundation (Week 1) ✅ COMPLETED

Database Setup

  • Configure Cloudflare D1 database binding in wrangler.toml
  • Create database schema file (schema.sql)
  • Create migration scripts
    • teams table
    • fixtures table
    • players table
    • availability table
    • final_selections table
    • Add indexes for performance
  • Create seed data script for testing
  • Test D1 connection from Worker

Worker API Structure

  • Set up D1 binding in worker/src/index.ts
  • Create API route structure
  • Add error handling middleware
  • Add CORS configuration
  • Create utility functions for database operations
  • Add UUID generation utility

Phase 2: Backend API (Week 2) ✅ COMPLETED

ELTTL Scraper

  • Research ELTTL HTML structure
  • Install HTML parser (node-html-parser)
  • Implement scrapeELTTLTeam(url) function
    • Extract team name
    • Parse fixtures table (date, time, home, away)
    • Parse squad/players list
    • Handle parsing errors gracefully
  • Add validation for scraped data
  • Write tests for scraper

Import Endpoint

  • POST /api/availability/import
    • Accept ELTTL URL in request body
    • Call scraper function
    • Generate team UUID
    • Save team to database
    • Save fixtures to database
    • Save players to database
    • Initialize availability records (all false by default)
    • Return team UUID and redirect URL
    • Handle duplicate imports
  • Add rate limiting
  • Add input validation

CRUD Endpoints

  • GET /api/availability/:teamId
    • Fetch team details
    • Fetch all fixtures with availability
    • Fetch all players
    • Fetch final selections
    • Return combined data structure
    • Handle team not found
  • PATCH /api/availability/:teamId/fixture/:fixtureId/player/:playerId
    • Update availability record
    • Return updated data
    • Add validation
  • POST /api/availability/:teamId/fixture/:fixtureId/selection
    • Validate exactly 3 players selected
    • Clear existing selections
    • Save new selections
    • Return updated selections
  • GET /api/availability/:teamId/summary
    • Calculate games played (past)
    • Calculate games scheduled (future)
    • Calculate selection rate per player
    • Return summary data

Phase 3: Frontend Foundation (Week 3) ✅ COMPLETED

Route Structure

  • Create frontend/src/routes/availability/+page.svelte (landing page)
  • Create frontend/src/routes/availability/new/+page.svelte (import form)
  • Create frontend/src/routes/availability/[teamId]/+page.svelte (main tracker)
  • Create frontend/src/routes/availability/[teamId]/+page.server.ts (SSR data loading)
  • Add navigation links from home page
  • Update ToolCard on home page to enable availability tracker

API Client

  • Create frontend/src/lib/api/availability.ts
    • importTeam(elttlUrl)
    • getTeamData(teamId)
    • updateAvailability(teamId, fixtureId, playerId, isAvailable)
    • setFinalSelection(teamId, fixtureId, playerIds)
    • getPlayerSummary(teamId)
  • Add error handling
  • Add loading states
  • Add TypeScript types for API responses

Basic Components

  • Create frontend/src/lib/components/availability/AvailabilityImportForm.svelte
    • URL input field
    • Submit button
    • Loading state
    • Error handling
    • Validation
  • Create frontend/src/lib/components/availability/FixtureCard.svelte
    • Match details (date, time, home, away)
    • Player availability checkboxes
    • Final selection UI (max 3)
    • Validation indicator
  • Create frontend/src/lib/components/availability/PlayerSummaryCard.svelte
    • Player name
    • Player icon/avatar
    • Stats display (played, scheduled, total)
    • Selection rate
  • Create frontend/src/lib/components/availability/AvailabilityTracker.svelte
    • Main container
    • Fixtures grid
    • Player summary section

Phase 4: UI Polish (Week 4) ✅ COMPLETED

Design Implementation

  • Fixture card styling
    • Header should have match date, teams playing and venue
    • The spacing between player rows should be consistent irrespective of the selection/remove buttons
  • Implement dark mode support
    • Dark mode colors for all components
    • Toggle respects existing darkMode store
  • Implement light mode support
    • Light mode colors for all components

Responsive Design

  • Mobile layout (< 640px)
    • Single column fixture cards
    • Simplified player summary
    • Touch-friendly controls
  • Tablet layout (640px - 1024px)
    • Two column fixture cards
    • Grid player summary
  • Desktop layout (> 1024px)
    • Three column fixture cards
    • Full player summary grid

Loading & Error States

  • Add skeleton loaders for fixtures
  • Add skeleton loaders for player summaries
  • Add empty states (no fixtures, no players)
  • Add error messages with retry options
  • Add success notifications
  • Add optimistic updates

Phase 5: Features & Testing (Week 5) ✅ COMPLETED

Validation & Business Logic

  • Add client-side validation for 3-player selection
    • Disable selection if < 3 available
    • Warn if > 3 selected
    • Highlight invalid fixtures
    • Add tooltips for disabled states
    • Show insufficient players warning
  • Add server-side validation
    • Verify selected players are available
    • Validate maximum 3 players
    • Return appropriate error messages
  • Implement past vs future match filtering
    • Mark past matches as read-only by default
    • Add edit mode toggle for past matches
    • Different styling for past matches
    • Opacity reduction when disabled
  • Calculate player summary statistics
    • Games played (past with final selection)
    • Games scheduled (future with final selection)
    • Total games
    • Selection rate percentage

Testing

  • Write unit tests for validation logic
  • Write E2E tests with Playwright
    • Validation state tests
    • Insufficient players warning test
    • Selection limit tests
    • Past fixtures read-only test
    • Edit mode toggle test
    • Player summary display test
  • Write integration tests for database operations
    • Team CRUD operations
    • Fixture CRUD operations
    • Player CRUD operations
    • Availability operations
    • Final selection operations
    • Complete workflow integration test
  • Add test coverage reporting
    • Vitest coverage for worker (v8 provider)
    • Playwright HTML and JSON reporters
    • Coverage scripts added to package.json
  • Run all tests and verify passing
    • Worker: 65 tests passing (4 test files)
    • Frontend Unit: 7 tests passing (1 test file)
    • E2E: Test suite created and ready (requires running app to execute)
    • Test configuration fixed (vitest excludes e2e folder)

Phase 6: Polish & Deploy (Week 6) ✅ COMPLETED

Performance Optimization

  • Add database query optimization
  • Add API response caching
  • Add frontend code splitting
  • Optimize images and assets
  • Add compression
  • Analyze bundle size

Monitoring & Analytics

  • Add logging for important events

Documentation

  • Add README for availability tracker
  • Document API endpoints
  • Add inline code comments
  • Create user guide
  • Add developer setup instructions

Deployment

  • Set up D1 production database
  • Configure production environment variables
  • Deploy Worker to Cloudflare
  • Deploy frontend to Cloudflare Pages
  • Test staging environment
  • Run smoke tests
  • Deploy to production
  • Monitor for errors
  • Announce feature to users

Future Enhancements (Post-MVP)

  • Add support for updating fixture changes from ELTTL
  • Implement polling for data updates
  • Add optimistic UI updates
  • Add conflict resolution
  • Consider WebSockets for future enhancement
  • Add error tracking (e.g., Sentry)
  • Add analytics (e.g., Cloudflare Analytics)
  • Add performance monitoring

Notes

Database Schema Reference

teams (id, name, elttl_url, created_at, updated_at)
fixtures (id, team_id, match_date, day_time, home_team, away_team, venue, is_past, created_at)
players (id, team_id, name, created_at)
availability (id, fixture_id, player_id, is_available, updated_at)
final_selections (id, fixture_id, player_id, selected_at)

API Endpoints Reference

  • POST /api/availability/import → { teamId, redirect }
  • GET /api/availability/:teamId → { team, fixtures, players, availability, finalSelections }
  • PATCH /api/availability/:teamId/fixture/:fixtureId/player/:playerId → updated availability
  • POST /api/availability/:teamId/fixture/:fixtureId/selection → updated selections
  • GET /api/availability/:teamId/summary → player statistics

Key Validation Rules