daniel/deepdrft
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 13 Wiki Activity

docs: update cascade type references and close resolved TODO item

Browse Source
This commit is contained in:
daniel-c-harvey
2026-06-03 12:40:49 -04:00
parent 12383874c2
commit b8a51e4656
2 changed files with 4 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TODO.md
-8
View File
@@ -4,14 +4,6 @@ Pre-existing bugs and known issues not yet triaged into the roadmap. Items here
---
## Player controls do not activate — cascade type mismatch [CRITICAL]
Full analysis in `PLAYER_ANALYSIS.md` (2026-06-03).
- **Symptom:** Backend streaming works; player controls never respond. Clicking a track does nothing visible, the dock never expands, transport buttons render disabled.
- **Root cause:** `AudioPlayerProvider.razor` publishes `<CascadingValue Value="@(_audioPlayerService)">` where `_audioPlayerService` is typed as the concrete `StreamingAudioPlayerService`. Blazor binds cascading values **by the declared `TValue` type**. Every consumer asks for an interface — `AudioPlayerBar` / `SpectrumVisualizer` want `IStreamingPlayerService`, `TracksView` / `Home` want `IPlayerService` — so **none match the cascade and all receive `null`.** Null-guarded controls render disabled and silent; `TracksView.PlayerService` is `required` and will throw on first click once the bar alone is fixed.
- **Fix shape:** Type the provider field/cascade as a single interface (`IStreamingPlayerService`) and align all four consumers to it; or register the service in DI and use `AddCascadingValue<IStreamingPlayerService>`. Minimal correct move is the former. Detail in `PLAYER_ANALYSIS.md §2.3`.
## Player stack — adjacent correctness/hygiene issues
Surfaced by the same 2026-06-03 analysis (`PLAYER_ANALYSIS.md §4`). Distinct from the cascade bug.