veza/apps
senke feb5fc02be refactor(web): migrate trackService to orval-generated track client (v1.0.8 B5)
Third feature-service migration after B3 (profile) / B4 (playlist).
Replaces raw apiClient calls in @/features/tracks/services/trackService.ts
with orval-generated functions from services/generated/track/track.ts.
All public function signatures preserved — none of the 10 consumers
(useMyTracks, ListenTogetherPage, ExploreView, TrackList, TrackDetailPage,
TrackLyricsSection, TrackMetadataEditModal, etc.) need to change.

Functions migrated (10):
- getTracks         → orval getTracks (with AbortSignal via RequestInit)
- getTrack          → orval getTracksId
- getLyrics         → orval getTracksIdLyrics
- updateLyrics      → orval putTracksIdLyrics
- getSuggestedTags  → orval getTracksSuggestedTags
- updateTrack       → orval putTracksId
- deleteTrack       → orval deleteTracksId
- searchTracks      → orval getTracksSearch
- likeTrack         → orval postTracksIdLike
- unlikeTrack       → orval deleteTracksIdLike
- recordPlay        → orval postTracksIdPlay

Functions still on raw apiClient:
- downloadTrack     → orval getTracksIdDownload doesn't preserve
                      responseType: 'blob'; per-call responseType
                      override needs B9 cleanup pass.
- uploadTrack /     → delegate to uploadService (chunked transport
  getTrackStatus      lives there, separate concern from CRUD).

Two helpers (unwrapPayload, pickTrack) normalise the {data: ...} APIResponse
envelope and the {track: ...} single-resource shape, mirroring the B4
playlist pattern.

getTracks keeps its sortOrder param in the public signature for
forward-compat, but the orval call drops it — the backend swaggo
annotation on GET /tracks (track_crud_handler.go) declares only
sort_by, and the handler ignores any sort_order arg silently. Same
deferral pattern as B4. Re-enable when the backend annotation is
extended (v1.0.9).

Error handling preserved verbatim — AxiosError still propagates from
the orval mutator (Axios under the hood), so the existing status-code
→ TrackUploadError mapping (401 / 403 / 404 / 400 / 500 / network)
continues to apply unchanged.

Tests: trackService has no dedicated test file (trackService.test.ts
doesn't exist). Adjacent feature suites all green:
- src/features/tracks/  → 553/553
- src/features/player/, library/, components/dashboard, social →
  400/400

npm run typecheck: clean.

Bisectable: revert this commit → service returns to apiClient pattern.
No interceptor changes, no data-shape drift.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-25 23:17:29 +02:00
..
web refactor(web): migrate trackService to orval-generated track client (v1.0.8 B5) 2026-04-25 23:17:29 +02:00