in JavaScript

Why does ES6 have modules?


hackjam-london-2

Last March 24, 2016 we had our first meetup at the JavaScript Lab London and it turned out to be an interesting “experiment”.

One of the things that really drives me is understanding the why of things and help others to understand it too. In this case the goal was to understand why ES6 has modules.

Our meetup is about learning by doing. So we created a repo in Github with an Angular 1.5 app using ES5 (https://github.com/Philos-io/hackjam-es6-angular-london). We explained a bit about ES6 (http://www.slideshare.net/AlexLobera1/js-lab-london-hack-jam-1) and then attendees had to migrate the Angular app to ES6 with the help of some mentors.

Migrating an Angular 1.X app to ES6 is very interesting because Angular 1.X has its own dependency injection system, so you end up defining dependencies in two different places (that’s confusing).

We suggested two approaches to migrate the app. One approach was to migrate the entry point file,  to make sure the app worked (as easy as looking at the terminal or the website since we were using webpack -w). Then to migrate a file that depended on the main file, then to check. Then to migrate the next dependency of that file, and so on. The other way was to migrate all the files at once… it’s a small app.

Here is what happened:

1. People who tried to migrate all at once didn’t finish and had a broken app. The ones who did it incrementally either migrated the entire app or just migrated part of it but they had a working app. Migrating apps incrementally (no matter the tech) is in general a good idea.

2. One guy migrated the whole app to ES6. He put all the app’s dependencies in the main file. He did it fast, he had an Angular app using ES6 and the app was working. He asked: “what is the point of using modules?“ He understood how to create modules, but obviously he didn’t understand why.

src/index.js:wrong-es6-modules 2

3. Some people wondered where to put Angular module definitions (yes, it was confusing managing dependencies in two different ways, Angular + ES6 modules). There were 2 options. Option A) leave them where they were before. Option B) move them to another file.

Code before ES6 refactoring:

https://github.com/Philos-io/hackjam-es6-angular-london/blob/master/src/modules/common/index.js

https://github.com/Philos-io/hackjam-es6-angular-london/blob/master/src/modules/common/nav/navcontroller.js

Option A. Code after ES6 refactoring:

src/modules/common/nav/navcontroller.js:coupling-angular

Option B. Code after ES6 refactoring:

https://github.com/alexlbr/hackjam-es6-angular-london/blob/master/src/modules/common/index.js

https://github.com/alexlbr/hackjam-es6-angular-london/blob/master/src/modules/common/nav/navcontroller.js

Option B) brings a great separation of concerns. All the Angular dependencies of that component are managed in that index.js. That way NavController is just a JavaScript file, it could use Angular, React or whatever framework because it’s not coupled. That makes it even easier to test since you don’t have to mock Angular.