-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
Make initListeners more general. #2773
Conversation
Also, look in the component's options themselves and not just children for components to initialize.
@@ -369,6 +369,10 @@ class Component { | |||
// If there's no .player_, this is a player | |||
let ComponentClass = Component.getComponent(componentClassName); | |||
|
|||
if (!ComponentClass) { |
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.
abort trying to make a component if it doesn't exist.
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.
Should this throw an exception instead?
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.
Elaborating a bit-- if a bad component was encountered midway through player creation, this would abort early and return a player missing a chunk of itself. It seems like a bad component name is a development-time-misconfiguration and it might be better to fail fast and force a fix.
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.
Children could also, theoretically, be configured dynamically, in which case, we possibly don't want to throw.
However, now that I'm making sure that everything is a component below, I guess I probably don't even need to have this section here and leave it as what it was.
Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED Commit: 13f524c (Please note that this is a fully automated comment.) |
} | ||
|
||
workingChildren.concat(Object.getOwnPropertyNames(this.options_)) |
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.
workingChildren
is either the array of children or a list of the object properties from the children
object.
We then want to concatenate it with the list of all names from options
, since that could contain other children we want to add.
Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED Commit: a543d4d (Please note that this is a fully automated comment.) |
} | ||
|
||
workingChildren.concat(Object.getOwnPropertyNames(this.options_)) | ||
.map((child) => { |
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.
get everything into the same format of [{name, options}, ...]
// See https://github.com/videojs/video.js/issues/2772 | ||
let c = Component.getComponent(child.opts.componentClass || | ||
toTitleCase(child.name)); | ||
return c && !Tech.isTech(c); |
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.
Ignore techs and not components. Techs need to be ignored specifically because of #2772.
Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED Commit: 8000460 (Please note that this is a fully automated comment.) |
Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED Commit: 1c82bc9 (Please note that this is a fully automated comment.) |
It's failing in IE9 and 10 because those don't have |
Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED Commit: 80c5172 (Please note that this is a fully automated comment.) |
Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED Commit: b4bc4b8 (Please note that this is a fully automated comment.) |
Object.getOwnPropertyNames(children).forEach(function(name){ | ||
handleAdd(name, children[name]); | ||
}); | ||
workingChildren = Object.getOwnPropertyNames(children); |
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.
Out of curiousity, is there a reason we're using Object.getOwnPropertyNames
instead of Object.keys
in many/most places (not just this PR)?
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.
Not sure.
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.
It's pretty much an incidental difference for our purposes: keys
includes only enumerable properties where getOwnPropertyNames
includes non-enumerable properties.
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.
Seems like keys
would be the right mechanism here to me.
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.
Switched to use keys
.
Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED Commit: 59a509e (Please note that this is a fully automated comment.) |
@pam retry |
Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED Commit: 59a509e (Please note that this is a fully automated comment.) |
@pam retry |
Tests passed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: CONFIRMED Commit: 59a509e (Please note that this is a fully automated comment.) |
No tests? 😄 |
@misteroneill what are tests? :P |
Tests passed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: CONFIRMED Commit: bfeb3a4 (Please note that this is a fully automated comment.) |
Do we have sufficient coverage for the various permutations of |
I'm updating tests for that currently. Currently there's an issue where you might end up with two components if add settings to a component (rather than disabling it). |
We don't want to actually run uniq because if the childrens array has multiple items, we do want multiple items in that case. However, we don't want to add more children of a kind if it is also available in options. So, we filter those out.
Tests passed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: CONFIRMED Commit: 2056048 (Please note that this is a fully automated comment.) |
LGTM! |
@@ -521,33 +528,65 @@ class Component { | |||
// Add a direct reference to the child by name on the parent instance. | |||
// If two of the same component are used, different names should be supplied | |||
// for each | |||
this[name] = this.addChild(name, opts); | |||
let newChild = this.addChild(name, opts); | |||
if (newChild) { |
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.
If you agree with my suggestion above, this part could be reverted.
Tests passed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: CONFIRMED Commit: 88f92b0 (Please note that this is a fully automated comment.) |
Tests passed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: CONFIRMED Commit: a1583ee (Please note that this is a fully automated comment.) |
Test that it throws correctly.
Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED Commit: 6bf3bb4 (Please note that this is a fully automated comment.) |
@pam retry |
Had a discussion about reducing the calculation of |
Also, look in the component's options themselves and not just children
for components to initialize.
Fixes #2767, has issues around #2772.