Replies: 2 comments 9 replies
-
|
High level I think this is 🔥. Just trying to think through some things. Since
At a high level, we could think of this as 2 different pieces: 1) A data contract; 2) A UI that "knows about" and is responsive to/can provide updates via (1). I have some additional thoughts/could throw out a few other straw men proposals, but wanted to start with some seed planting. |
Beta Was this translation helpful? Give feedback.
-
|
I have a slightly different proposal, for the media-playlist-items specifically. Instead just use media elements as the items, and media-playlist becomes a custom media element itself, encapsulating the logic of rotating medias internally. <media-controller>
<media-playlist slot="media">
<video src="...">
<audio src="..." preload="none">
<youtube-video src="..." preload="none">
</media-playlist>
</media-controller>This approach gets around any need for the playlist to understand differences between custom media elements. e.g. how do I handle a youtube source or text tracks? x-playist is a similar demo I built years ago and could be a starting place. The alt to that approach is to just build <media-controller>
<video src="..." slot="media">
<audio src="..." slot="media" preload="none">
<youtube-video src="..." slot="media" preload="none">
</media-controller>With either, we'll also need to standardize some events, like We might also consider the fact that the youtube player can go through a playlist itself, so a "next()" API might need to become a media-ui-extension. |
Beta Was this translation helpful? Give feedback.
-
Sure, that follows the same communication pattern, but not the same architecture. Creating I want to dig into the |
Beta Was this translation helpful? Give feedback.
-
|
Isn't that exactly what MEDIA_PREVIEW_REQUEST: (e) => {
const media = this.media;
// No media (yet), so bail early
if (!media) return;
const [track] = getTextTracksList(media, { kind: TextTrackKinds.METADATA, label: 'thumbnails' });
// No thumbnails track (yet) or no cues available in thumbnails track, so bail early.
if (!(track && track.cues)) return;
const time = e.detail;
const cue = Array.prototype.find.call(track.cues, c => c.startTime >= time);
// No corresponding cue, so bail early
if (!cue) return;
// Since this isn't really "global state", we may want to consider moving this "down" to the component level,
// probably pulled out into its own module/set of functions (CJP)
const url = new URL(cue.text);
const previewCoordsStr = new URLSearchParams(url.hash).get('#xywh');
this.propagateMediaState(MediaUIAttributes.MEDIA_PREVIEW_IMAGE, url.href);
this.propagateMediaState(MediaUIAttributes.MEDIA_PREVIEW_COORDS, previewCoordsStr.split(',').join(' '));
},(from https://github.com/muxinc/media-chrome/blob/main/src/js/media-controller.js#L142-L164) |
Beta Was this translation helpful? Give feedback.
-
|
Not exactly, but fair point. Nothing else in the system relies on the state of a preview component. We can build multiple components using the preview-related events, and it won't cause any conflicts between those components or anywhere in the system. They're also dependent on centralized state, the preview thumbnail track. I can't say the same about a media-playlist. If there were two playlists, and something needs to know the "current-playlist-item", which is it? If one playlist successfully advances and the other doesn't, what happens? Unless I'm missing a detail of the approach, dependency on the state and results of media-playlist operations then require a way for media-playlist to inform media-controller of state in the same way media elements inform media-controller. If we use events for that, they're ultimately system-driven events, not user-driven like the existing Is complexity the only reason we wouldn't go the path of making media-playlist a media-element? I don't think it'd be nothing, but we can follow the patterns of custom-video or even subclass to make it not crazy. |
Beta Was this translation helpful? Give feedback.
-
|
I'm most concerned about (1) complexity and (2) introducing an additional point of failure for data flow. Each time we implement a component that "wraps" another component, we have another place where we need to maintain parity, which becomes more complex as we extend beyond the |
Beta Was this translation helpful? Give feedback.
-
|
If we're ok with accepting that cost of maintenance/risk (which will require a "swiss army knife" approach to anything that fits within this architectural pattern), then that's fine, but just want to highlight it as a risk & cost. |
Beta Was this translation helpful? Give feedback.
-
Note: This isn't a Super Formal proposal, this is intended to be a "hey what if" and a test of using discussions for it 😅
The other day I needed to create a playlist, and it made me yearn for something like the
videojs-playlistfunctionality. There would need to be quite a bit of thought around what the UI would look like for showing the playlist items, but to keep things simple assume this proposal is starting at just an auto-advancing playlist of media items.For the most simple use-case, my thought is that we can start with 4 new elements:
<media-playlist>The parent element of all the playlist items (
<media-playlist-item>). This element would also be where the playlist behavior was configured, such as autoadvancing, looping, pre-fetching behavior, etc.<media-playlist-item>This gets a little weird, admittedly. In my mind this is mostly the same as a
<source>tag, but should also accept things likeposter.<media-playlist-previous-button>Button to be used in the
control-barfor returning to the previous playlist item.<media-playlist-next-button>Button to be used in the
control-barfor advancing to the next playlist item.Full example
Beta Was this translation helpful? Give feedback.
All reactions