Re-expose TextTrack

[misteroneill]

Fixes #2623

[pam]

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

Commit: c7dd29bc6de68228dec4098b490fe4df7c1f234b
Build details: https://travis-ci.org/pam/video.js/builds/81602820

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

[gkatsev]

LGTM. Though, still feels a bit weird to register it as a component.
Also, do we want to expose the other text track definitions as well? I guess those can wait till 5.1 if needed.

[heff]

Yeah, components are a pretty specific concept in video.js with expected functions and such, so I don't think it's safe to register TextTrack as one, at least as it is. And maybe more importantly we don't want to set a trend of registering non-components this way.

I think if we want this done quickly we should just export TextTrack onto the videojs object.

[misteroneill]

I agree that it's weird as a component. Would it be preferable to simply expose it as videojs.TextTrack? Ultimately, it might make sense to have a getter/setter for non-component classes in the future.

[dmlap]

+1 to videojs.TextTrack. I don't think we should add getters/setters for this sort of thing. It's just a class, we don't need a dynamic lookup mechanism for it.

[misteroneill]

I thought it might make sense for consistency with getComponent/registerComponent, but that's neither here nor there.

I'll make the change to expose it as a property of videojs instead.

[heff]

lgtm

[pam]

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

Commit: e220c10
Build details: https://travis-ci.org/pam/video.js/builds/81609899

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