hasClass() is available in dev but not in prod

[nwoltman]

This is another Closure Compiler problem. videojs.Component.prototype.hasClass exists in the dev file but not in the prod file.

[mmcc]

We're moving away from GCC for v5 (#1586), so this (and mangling issues like it) shouldn't be an issue in the near future. Just out of curiosity, what are you using hasClass for in the wild?

[nwoltman]

I'm working on a plugin and I just need to check if the player is using native controls. I looked through the documentation and couldn't find a friendly way to do this so the only way I could see to check if the player is using native controls is to check the player's class for "vjs-using-native-controls".

Perhaps the player or the control bar could have a .isUsingNativeControls() method?

[nwoltman]

@MMC I found what might be a better way to check if a player is using native controls:

video.techName === 'Html5' && video.tech.el().controls

Although it looks like the techName and tech properties are mangled by the GCC in the latest production version. Is there a "more correct" way to do this sort of check? I remember reading somewhere that the tech* properties shouldn't be used, but I don't see any other way to get this information.

[mmcc]

Since we use class names so extensively for handling view state, I think using it for this makes a lot of sense. We consider checking the tech to be a quasi-bad practice (#1234), so I would discourage going that route.

That being said, I can think of a few other options that might work for you:

• There's the usingNativeControls method. This is private for a reason, but I think using it as a getter in your case could make sense.
• You could check the nativeControlsForTouch option. It has to be explicitly set to true for native controls to be used.

[nwoltman]

Ah I see. I had looked at the usingNativeControls method, but when I called it it returned undefined, so I wasn't sure that it was working properly. I guess that was just because it isn't initially set to false here.
That got me thinking though, shouldn't private properties like that be initialized in a constructor and not on the object's prototype since the value isn't being shared between different instances of the object?

[mmcc]

Yeah, the undefined bit honestly threw me for a second when I checked to make sure it was exported. I would say we should change that, but since it's technically private I guess it shouldn't matter.

I'm not sure I follow the constructor / prototype bit, but I think there's a bit of confusion as to what we intend by private here. Other VJS classes internally need access to this, but it isn't intended to be used externally as we are here. Normally methods like this aren't exported by GCC and as such are actually private from the outside world, so this is a bit of a weird example.

[nwoltman]

Sorry, I should have been more specific. It is correct to have the usingNativeControls function on the object's prototype, but the usingNativeControls_ variable that that function uses doesn't make sense to be on the prototype. On this line where the value is set, a new property is actually being created on the object, so then you end up with two properties; one at this.usingNativeControls_ and one at player.Component.prototype.usingNativeControls_ (or this.__proto__.usingNativeControls_ if it's easier to think about that way).

[nwoltman]

Fixed in 265ed0e