Discussion: CustomMediaElement

[cjpillsbury]

Proposal - CustomMediaElement (plus decisions on where it lives)

Our original goal was to use CustomVideoElement as the superclass of mux-video. For the short term, we ended up instead duplicating it with minor changes to meet our immediate goals for mux-video. Since we may eventually want to promote our changes back to CustomVideoElement, we intentionally kept these changes narrow.

However, given the very similar needs of mux-audio on a nearly identical CustomAudioElement, we may want to consider creating a more generic CustomMediaElement.

Things we should come to a decision on before Beta Release

Should we update https://github.com/muxinc/custom-video-element at all (this would include changes made for 0.1 release)?

• Detriment: There are other projects/repos with dependencies on it and no regression tests in place, e.g. HLSVideoElement and DASHVideoElement

Should we create a new superclass, CustomMediaElement?

• Consideration: This is an open question for either an "internal mux-element" version or an updated CustomVideoElement

If we create a new CustomMediaElement, do we still need a CustomVideoElement and CustomAudioElement

• Consideration: Currently, we would need something like these based on the dynamic updates to the prototypes that occur on module load of e.g. CustomVideoElement. However, this could be refactored to work differently such that these "intermediary" and almost identical class definitions would be unnecessary.

Should mux-elements have a dependency on either an external CustomVideoElement & (a new) CustomAudioElement or CustomMediaElement (the alternative would be to have something defined in mux-elements instead)?

• Benefit: mux-video and mux-audio would get any new features or bug fixes for free that may be identified from folks using it independently of mux-elements.
• Detriment: CustomVideoElement is not (currently) managed as a "mature, production-ready package" (with robust tests, robust semver management, both also directly related to any packages that depend on it, etc.)
• Detriment: There is a high probability that this will slow down forward progress on any mux-elements with these dependencies, at least in the short term.
• Detriment: While not definitive, it's conceivable that we could need changes to e.g. CustomMediaElement or CustomVideoElement that we would not want in a shared version of these custom elements. This is plausible in particular as we start adding more explicit support for app framework implementations of mux-elements

NOTES:

• This decision needn't be set in stone, though at least a short-term decision should be made early enough before our target beta release to make forward progress, establish required tasks for go live, and the like. If deemed appropriate, we can schedule a future time to revisit any decisions made for our short- to mid- term goals.