Separate media-controller from media-container

[heff]

Related to v1.0 and themes, I've been thinking about a more clear split between the controller and the container. Would love additional thoughts.

They are separate components today, but from a user perspective, they're not different. The proposal would be to make them different from a user perspective.

Combined pros/cons

• One element instead of two, when in most cases two may not bring any added benefit
• Feels like same shape as <form> to <button> relationship, rather than something more complex with more moving parts

Split apart pros/cons

• More clear use case of using container + other UI els without media-chrome's controller if desired, i.e. other professional players just wanting the UI components and themes
• Build a react-specific controller to avoid sprouting attr issues
  • When copying out of Themes, you would not be copying the controller along with the UI-only components, making it easier to translate themes from vanilla HTML to the React world

General proposal shape:

Vanilla HTML

<media-controller controllerattr="..."></media-controller>
<media-container>
  <video slot="media"></video>
  <media-control-bar>...</media-control-bar>
</media-container>

• For convenience, either media controller element assumes next sibling is the container, or media-container auto registers itself with prior media-controller sibling. Otherwise can still manually connect the two with media-controller attr.

Vanilla example with no media-controller element, only media controller object.

<media-container id="blah">
  <video slot="media"></video>
  <media-control-bar>...</media-control-bar>
</media-container>

<script>
  const mc = new MediaController({ ...options });
  const container = document.getElementById('blah');
  mc.associateElement(blah)
</script>

• No media controller element required if you're working in javascript.

React example -- would love help fleshing this out clearly

[luwes]

I don't really see the need for the split in the vanilla HTML example.
why can't the user choose either media-controller or media-container?

Automatic

<media-controller>
  <video slot="media"></video>
  <media-control-bar>...</media-control-bar>
</media-controller>

or

Manual

<media-container>
  <video slot="media"></video>
  <media-control-bar>...</media-control-bar>
</media-container>

I def choose to keep it combined if this means users would need to add both media-container and media-controller

[heff]

@luwes do you get the React example here? We're pushing towards a world where we have MediaControllerReact (for sprouting and other reasons). If I open up a Theme or example that uses media-controller as the container, and try to copy and paste the contents into MediaControllerReact, you end up with two controllers, and that needs to be resolved somehow. "Make sure to change 'media-controller' to 'media-container'" isn't a particularly elegant solution IMO.

[cjpillsbury]

Just for additional visibility, I've created an over-arching discussion thread (that references this one) here: #529

[heff]

Goals:

Outlining some goals I'm understanding after some feedback and the controller refactoring.

• Easily copy themes/examples between React (using a MediaControllerReact component) and vanilla JS uses
• Controller portability, so it can live natively in different environments
• Separation of concerns and independent component usage (we're not building a player, we're building player components)

Object Ownership

With the refactor I'm seeing these lines of ownership between MediaControllerObj, MediaControllerElement, and MediaContainer.

MediaController (object not element)

• media element
  • Keep ref to the media element
  • set/get/handle requests to change the media element
• Media state receivers
  • Keep ref to all elements that should be pushed media state
  • Allow registering and unregistering
  • Push state to them when updated
• Associated elements (UI containers?)
  • Keep ref to associated elements where new state receivers might be discovered
  • Capture UI request events at this level
• Keep ref to fullscreen element
  • Allow overriding
• Allow overriding defaults/options
  • e.g. defaultStreamType
• Maintain volume prefs between playback

<media-controller> (element specific)

• HTML-only UI
• Allow setting options as element attributes
  • e.g. default-stream-type

<media-container>

• All UI layout related features
  • Allow styling via attributes (this is not a controller feature, it's a feature of a container)
• User activity related to the media element (hovering, clicking)
• Keyboard shortcuts when the media/player is in focus (should move to container, right?)
• Default fullscreen element unless overridden
• Emit events when the state changes? All elements should emit (non-bubbling) state change events for the specific media attributes they care about. And media-container cares about all of them for styling purposes. While the MediaControllerObj shouldn't fire change events itself and complicate the use of the controller.

[cjpillsbury]

MediaController (object not element)
...

• Media state receivers

  • Keep ref to all elements that should be pushed media state
  • Allow registering and unregistering
  • Push state to them when updated

• Associated elements (UI containers?)

  • Keep ref to associated elements where new state receivers might be discovered
  • Capture UI request events at this level

We probably don't want to deeply tie these to our primary JS state mgmt code, as they assume particular ways of updating state and receiving state change requests as direct HTML (/Web Component) updates instead of agnostic (so as to make framework-specific usages easier). This is called out in the larger discussion I posted ☝️(#529).

[heff]

Does it hurt if they're included but optional? Otherwise there's a hypothetical world where there's a generic controller, a web-specific controller, and a controller element. That feels like a lot.