Skip to content
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

Feature/current source #2678

Merged
merged 3 commits into from
Nov 3, 2016
Merged

Conversation

chemoish
Copy link
Member

@chemoish chemoish commented Oct 6, 2015

Original PR: #2479

@pam
Copy link

pam commented Oct 6, 2015

Tests passed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: CONFIRMED

Commit: 4dc3e77
Build details: https://travis-ci.org/pam/video.js/builds/83938385

(Please note that this is a fully automated comment.)

@chemoish
Copy link
Member Author

Addresses #2443

@chemoish
Copy link
Member Author

@heff Any status updates?

@chemoish chemoish mentioned this pull request Oct 28, 2015
18 tasks
@gkatsev
Copy link
Member

gkatsev commented Nov 9, 2015

Unfortunately, I don't think we'll get it in a 5.2 release but I'll definitely take a look at it next.

@gkatsev gkatsev added the minor This PR can be added to a minor release. It should not be added to a patch release. label Nov 24, 2015
@gkatsev gkatsev added the needs: LGTM Needs one or more additional approvals label Jan 26, 2016
@gkatsev
Copy link
Member

gkatsev commented Feb 2, 2016

Looks like this needs to be rebased against master :)
Also, this mostly looks good. One thing that we should double check is that it's working correctly with things like source handlers. I don't foresee any issues but best to check it out.

@gkatsev gkatsev removed the needs: LGTM Needs one or more additional approvals label Feb 3, 2016
Carey Hinoki added 2 commits August 26, 2016 15:23
…ource objects—when using `<source>` or `src()`.

This is needed for source retrival for two use cases:
- preroll
- resolution switch (kind of)

Currently there is no way of accessing the source object for any DRM specified content. Plugin access only has API methods to `currentSrc` and `currentType`.

This will allow for `currentSource` and `currentSources` to return unverified source object(s).

# Conflicts:
#	src/js/player.js
#	test/unit/player.js
…urce, have the current sources be set to null.

When the `currentSources()` are called after `src('http://example.com')`, expect the `currentSources()` to only return the newly set source.
This way sources, via `<source>` or `src([...])` list, should never be out of sync when redefining a single source.

Updating tests to specify behavior changes. Remove autoplay from fixtures to bypass `loadTech()` ramifications.

# Conflicts:
#	src/js/player.js
#	test/unit/player.js
* @method currentSource
*/
currentSource() {
return this.cache_.source || { src: this.currentSrc() };
Copy link
Member Author

@chemoish chemoish Aug 26, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds fine to me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My initial thought is to throw away all the code for currentSrc() since now is very duplicative and loses information such as type. Though this is a breaking change and there is probably a big hole in my logic.

Atm, currentSrc() returns a string or undefined

I think it makes sense to translate that across those methods.

currentSrc() === undefined
currentSource() === undefined
currentSources() === undefined

vs.

currentSrc() === undefined
currentSource() === { src: undefined } or {}
currentSources() === [{ src: undefined }] or []

So I would recommend undefined or {} and [].

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I lean toward all three methods returning undefined if there is no source.

My second preference would be {} or [] for the two new ones, but I feel like in that case, it would make more sense for currentSrc to return '' instead of undefined.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, undefined would be not backwards compatible but also would break away from what the video element does for currentSrc:

document.createElement('video').currentSrc
// ""

As for the others, returning an empty object and empty array would make it consistent. Though, would be a bit annoying to check for whether it's empty or not.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh! I thought currentSrc returned undefined. In that case, I vote for currentSource to return undefined and currentSources to return [].

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having currentSource return undefined seems inconsistent to me. Both from it's internal type signature but also between the 3 methods.
currentSrc always returns a string and currentSources always returns an array, why should currentSource be different?

@chemoish
Copy link
Member Author

chemoish commented Aug 26, 2016

@chemoish
Copy link
Member Author

@gkatsev any update?

Copy link
Member

@gkatsev gkatsev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gesinger do you have any changes that we should apply to this PR and merge?

@gesinger
Copy link
Contributor

@gesinger
Copy link
Contributor

On second thought, I think it is fine either way.

…Source` to return `{}` when `src` is `''`.

NOTE: these tests only pass because they are hitting the `cache_`.

- Fix tests
- Add method to `TechFaker`
Copy link
Member Author

@chemoish chemoish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gesinger @gkatsev @misteroneill Update per initial conversation, minor to change again.

(First time trying this review tool)

I don't know how to properly test src changes as there isn't any other tests that validate sources. It looks like I needed to update TechFaker for non-empty <source> tags with unspecified tech?, but in either case I don't think it properly tests the methods—only the cache_?

* @return {Object[]} The current source objects
* @method currentSources
*/
currentSources() {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated to return [] when src is ''

const sources = [];

// assume `{}` or `{ src }`
if (Object.keys(source).length !== 0) {
Copy link
Member Author

@chemoish chemoish Sep 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seemed like a fine isEmpty check

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I don't know if it's merged yet, but I introduced utils/obj in a PR recently. An isEmpty could be useful there. If not, this is fine, I think.

* @return {Object} The current source object
* @method currentSource
*/
currentSource() {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated to return {} when src is ''

@chemoish
Copy link
Member Author

I looked for an isEmpty and every permutation/util in between. Could have
missed it, link and i'll update.

On Thu, Sep 22, 2016 at 5:16 PM, misteroneill notifications@github.com
wrote:

@misteroneill commented on this pull request.

In src/js/player.js #2678:

@@ -2062,6 +2070,41 @@ class Player extends Component {
}

/**

  • * Returns the current source objects.
  • * @return {Object[]} The current source objects
  • * @method currentSources
  • */
  • currentSources() {
  • const source = this.currentSource();
  • const sources = [];
  • // assume {} or { src }
  • if (Object.keys(source).length !== 0) {

Agreed. I don't know if it's merged yet, but I introduced utils/obj in a
PR recently. An isEmpty could be useful there. If not, this is fine, I
think.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2678, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhhxwTCjoDrtuABO6_i-LxdusFSLQO3ks5qsxpLgaJpZM4GJ8bx
.

sources.push(source);
}

return this.cache_.sources || sources;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we do the work of setting up the sources variable if we're just going to return this.cache_.sources?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know off the top of your head that sources will never get called because this.cache_ will always be present?

I most likely implemented this to follow suit of the original implementation—thinking that there will be a difference between <source> and src, but since the PR been open for some time I have no idea anymore.

I can investigate further if unknown.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is a big concern. It's fine to leave as is and we can always profile and increase performance in the future.

source.src = src;
}

return this.cache_.source || source;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same question here.

@gkatsev gkatsev added this to the 5.13 milestone Sep 27, 2016
Copy link
Member

@gkatsev gkatsev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just tried it out locally. Works great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed minor This PR can be added to a minor release. It should not be added to a patch release.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants