-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Airplay, Captions, and Cast button props #587
feat: Airplay, Captions, and Cast button props #587
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Codecov Report
@@ Coverage Diff @@
## main #587 +/- ##
==========================================
+ Coverage 77.84% 77.93% +0.09%
==========================================
Files 42 43 +1
Lines 7438 7600 +162
==========================================
+ Hits 5790 5923 +133
- Misses 1648 1677 +29
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fine for now but it seems like we're leaning towards an array of track-like objects. Feel free to update in this PR or merge and resolve as a followup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small non-blocker
|
||
// don't set if the new value is the same as existing | ||
const newValStr = stringifyTextTrackList(list); | ||
const oldValStr = stringifyTextTrackList(el.getAttribute(attrName) ?? ''); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: There's probably no need to stringify the attribute value as it's already stringified.
Adds missing props for the Airplay, Captions, and Cast buttons.
With captions specifically, we have to decide on the prop type for getting and setting a subtitles list. This is currently a simple array of strings. This matches how we store and retrieve the data from the attribute and also makes interacting with the prop similar to how a dev would interact with the attribute directly.
The alternative is to accept
TextTrack
's (or objects that are a subset with only the data we need). Is this preferable? I can see this being simpler for the developer assuming they haveTextTrack
's at hand.