You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a complicated one so deserves some explanation...
In 4.x we mangled private properties of the player (player.somethingPrivate_ --> player.a) including the tech. We've kept the tech private because it's extremely important to the video.js ecosystem that developers aren't building plugins that are locked to a specific tech. We should instead be aggressively abstracting video playback concepts at the player level so that they work the same across techs.
We've been able to maintain this for years through the combination of abstracting concepts and allowing users to pass configuration options to the techs (videojs.options.flash.foo = true). However with the new Source Handler interface and moving advanced formats like HLS and DASH into that model, it's put stress on this philosophy, because player users (not plugin developers) want to control unique aspects of those formats and their operation. #2616 is the first step, allowing configuration options to be passed to the source handlers.
For more advanced run-time configuration we want to give 'approved' access to the tech and source handlers, for users who are just configuring the formats, not publishing plugins to be shared.
The API we've come up with looks like this:
var tech = player.getTech({ IWillNotUseThisInPlugins: true });
If you don't include the object, it will alert() and throw a new Error(). The point of doing the alert is to inform even the newest developer who may not be working with the console open. We don't want to frustrate people with this, we just want to make sure they're informed.
The alert and error will show how to disable the error and a link to a blog post/issue explaining the situation.
Comment if you have any other thoughts on function or object key naming.
The text was updated successfully, but these errors were encountered:
This fixesvideojs#2617. It implements the function that expects an object with
the property IWillNotUseThisInPlugins. Otherwise, it will alert and
throw an error linking to issue videojs#2617.
Also, some tests.
This is a complicated one so deserves some explanation...
In 4.x we mangled private properties of the player (player.somethingPrivate_ --> player.a) including the tech. We've kept the tech private because it's extremely important to the video.js ecosystem that developers aren't building plugins that are locked to a specific tech. We should instead be aggressively abstracting video playback concepts at the player level so that they work the same across techs.
We've been able to maintain this for years through the combination of abstracting concepts and allowing users to pass configuration options to the techs (
videojs.options.flash.foo = true). However with the new Source Handler interface and moving advanced formats like HLS and DASH into that model, it's put stress on this philosophy, because player users (not plugin developers) want to control unique aspects of those formats and their operation.#2616 is the first step, allowing configuration options to be passed to the source handlers.
For more advanced run-time configuration we want to give 'approved' access to the tech and source handlers, for users who are just configuring the formats, not publishing plugins to be shared.
The API we've come up with looks like this:
If you don't include the object, it will
alert()and throw anew Error(). The point of doing the alert is to inform even the newest developer who may not be working with the console open. We don't want to frustrate people with this, we just want to make sure they're informed.The alert and error will show how to disable the error and a link to a blog post/issue explaining the situation.
Comment if you have any other thoughts on function or object key naming.
The text was updated successfully, but these errors were encountered: