-
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
ES6ification #1976
ES6ification #1976
Conversation
'textTrackSettings': {} | ||
}, | ||
|
||
'language': document.getElementsByTagName('html')[0].getAttribute('lang') || navigator.languages && navigator.languages[0] || navigator.userLanguage || navigator.language || 'en', |
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.
Where did these language options go? They're not in options.js.
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.
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.
lol. I added it back in my PR
@videojs/core-committers we're looking to get this one in quickly so we can start migrating the other open PRs. I know it's big but try to get any comments you have in now. |
Changes Unknown when pulling 3f20078 on mmcc:es6ification into * on videojs:master*. |
|
||
<!-- LOAD VIDEO.JS SOURCE FILES IN ORDER --> | ||
<script src="../build/source-loader.js"></script> | ||
<script src="../build/temp/video.js"></script> |
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.
Will the sandbox require a build before being usable now?
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.
Unfortunately yes. Browserify had no other option at least. But I guess now it might depend on what Chrome supports in ES6.
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.
Right now Chrome supports a good deal of what we've already implemented, but I don't think any browsers support ES6 modules, so Browserify is still a hard requirement.
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.
We should make sure we have a watchify
npm script we can use.
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.
We have grunt watch
now. Does that work?
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.
We could theoretically use grunt watch
but we really do want watchify
. watchify
caches the build so rebuilds take minimal amounts of time. That way, you can watchify
the build and then when you make a change and save you don't have to wait that long before you have to refresh the page.
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.
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.
I use watchify and karma's watch to have continuous tests running in videojs-playlist
This is a mega PR but I can't think of a better way to make this transition. I don't think we should shoot for a total, perfect conversion before pulling this in given the size of the migration. I say get it merged sooner rather than later so we can get more eyes on it. |
Even if it gets merged in, we could always continue to comment here. |
I would like a bit more time to a cursory glance at this PR, though. |
@dmlap yeah...I've had the same struggle. I hate both creating and reviewing PRs this big, but this is, unfortunately, an all or nothing transition. |
I mean, it's only 6000 changes. Just take your lunch hour and review 100 changes per minute. |
Also, just to reiterate, there are some other easy wins I think we can get from ES6, but I think they should be done in a different PR to minimize pain and suffering. This PR is just modules + let / const, the next PR can be default params and string interpolation. If we're going to move towards using classes and such, I think that should be its own PR. |
Changes Unknown when pulling 345445d on mmcc:es6ification into * on videojs:master*. |
@mmcc I'm with you on making this PR the minimal es6-ification and tacking the cool stuff in further updates. This is looking great! |
@dmlap sweet! @heff has already done some work towards the classes stuff, and we can get started on other sugar after this is merged in. Speaking of which, it'd be great if we can get this merged in tomorrow. Everyone should get any final comments in as soon as you can so other 5.0 work can be done off this branch. |
I'm seriously glad we are going in that direction. It's time to stop writing basic stuff like this and work on what really matters. I've been using ES6 with Babel in the past 3 months and it rocks. Big kudos @mmcc for doing that gigantic pull request. I would love to see the for loops transformed into the for-of loop. Much much cleaner and easier to read. You can read more about it here. An example for for (var i = 0; i < children.length; i++) {
let child = children[i];
let name, opts;
if (typeof child == 'string') {
// ['myComponent']
name = child;
opts = {};
} else {
// [{ name: 'myComponent', otherOption: true }]
name = child.name;
opts = child;
}
handleAdd(name, opts);
} Would become: for (let child of children) {
let name, opts;
if (typeof child == 'string') {
// ['myComponent']
name = child;
opts = {};
} else {
// [{ name: 'myComponent', otherOption: true }]
name = child.name;
opts = child;
}
handleAdd(name, opts);
} One other thing that would be interesting is also stop using our own event system. We should be using the EventEmitter inside the built-in The build looks fine to me:
|
vjs.createEl = function(tagName, properties){ | ||
var el; | ||
|
||
var createEl = function(tagName, properties){ | ||
tagName = tagName || 'div'; |
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.
default arguments.
Bad news if we want to use for-of: Array.isArray is not even IE8 compatible. The pollyfill is one line of code though. if (!Array.isArray) {
Array.isArray = function(arg) {
return Object.prototype.toString.call(arg) === '[object Array]';
};
} I don't think we need it at this point. I think it's worthless to talk about it at this point anyway. |
@eXon we're thinking of making es5-shim as requirement, so, might not be an issue. |
There's some open discussions on this still but nothing that seems to be blocking and can't be pulled out into its own issue, so merging this in. (phew!) @mmcc has updated the 5.0 change wiki page, and started the ES6 feature guide for contributors. ES6 Classes (#1993) is the next big one. At this point no one appears to be against the idea, we just need a clean migration story, so I'm going to move forward with it and hopefully get it in quickly. If we want to be ready by the end of April we need to keep moving fast, so we could certainly use help knocking down more of the 5.0 issues. |
Awesome! |
event.relatedTarget = event.fromElement === event.target ? | ||
event.toElement : | ||
event.fromElement; | ||
|
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.
This is a bit unrelated and I should raise an issue but ...
Can we add a check to see if event.relatedTarget exists??
Firefox supports it https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/relatedTarget and it does not support event.fromElement so in Firefox event.relatedTarget is undefined
:( We found this bug the other day.
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.
I don't see why not. Want to make a PR for it?
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.
Sure, where should I make the pull request? on this branch? is that possible?
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.
This PR is merged now, so you can just make it against master.
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.
Ups, I did not realize it was already merged. I will create the PR tomorrow morning.
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.
This isn't ready to merge yet...not even a little. I currently have a hacky way I'm going about getting tests working (custom es6 build), so that needs to be cleaned up and then another cleanup pass (or two...or 10).
I've purposefully kept this really light in terms of ES6 features. Once we've got this merged, I propose we take another pass at implementing a few more things that can be easy wins for readability, such as string interpolation and fat arrow functions. For this PR, I've only implemented
import
,let
, and the occasionalconst
. Becauselet
andconst
are block scoped, I've moved almost all declarations to the point of assignment (where applicable).There are some things such as VjsLib and VjsEvents that should be changed to just Lib and Events, and Utils should be merged with Lib.
So, if folks wouldn't mind taking a quick glance at 2,983 additions and 2,453 deletions across 66 files, that'd be wonderful. 👍
Related: #1720