feat: attachSource, the delivery layer without the control bar - #1
Merged
Conversation
Three of the apps meant to adopt this already have a player, and they are not
thin ones: p0dcasters runs a 511-line queue-aware dock, rssamplifier has a
dock plus a playlist player, and media-streamer has a modal per source with
its own retry and favourites. Handing them `createPlayer` would mean deleting
queues, next/previous and video.js to gain a nicer-looking bar. That is a
regression dressed as an adoption.
What all three DO need is the half below the UI: which engine plays this
source. Each answers it separately today, which is how a podcast shipping an
HLS enclosure plays on one of our sites and not another.
So `attachSource(media, { src })` picks the engine, attaches it, and hands
back something that lets go. No DOM, no styles, no opinions about the host's
UI. `createPlayer` now calls it too rather than keeping a second copy of the
ladder -- a second copy is the one that stops matching.
One behaviour change falls out and is an improvement: an unplayable source no
longer attaches a native engine as a consolation. Pointing a <video> at an
.m3u8 it cannot parse replaced a precise reason ("this browser cannot play HLS
streams") with a generic media error a few seconds later.
8 new tests; 79 pass, tsc and prettier clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WFLwZtXE6iBJyJSgrsWqRM
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adopting this package across the other sites turned up something worth acting on: three of the five already have a player, and none of them is thin.
player-entry.js, mpegts, live IPTVHanding the last three
createPlayerwould mean deleting queues, next/previous and video.js to gain a nicer-looking bar. That is a regression dressed as an adoption.What all three do need is the half below the UI — which engine plays this source. Each answers it separately today, which is how a podcast shipping an HLS enclosure plays on one of our sites and not another.
No DOM, no styles, no opinions about the host's UI.
createPlayernow calls it too, so there is one engine ladder rather than two that drift.One behaviour change, and it is an improvement
An unplayable source no longer attaches a native engine as a consolation prize. Pointing a
<video>at an.m3u8it cannot parse replaced a precise reason ("This browser cannot play HLS streams") with a generic media error a few seconds later.Checks
8 new tests covering engine choice, the iOS fallback, that it creates no DOM and touches no classes, that destroy really lets go, and that an unplayable source reports rather than attaches. 79 pass overall;
tscand prettier clean.🤖 Generated with Claude Code
https://claude.ai/code/session_01WFLwZtXE6iBJyJSgrsWqRM