-
Notifications
You must be signed in to change notification settings - Fork 86
ES6 modules migration
Benjamin edited this page Nov 22, 2017
·
19 revisions
Previous architecture / shortcomings
- a unique "one-ring to rule them all"
ngeo
Angular module (+ one for gmf) -
src/ngeo.js
/contribs/gmf/src/gmf.js
is a holdall (namespace, root Angular module, ...) - each Angular piece of code does
goog.require('ngeo')
and registers itself into the "one-ring" module - a ton of "ignore unused require" annotations
New modular architecture
- the ngeo namespace stays in
src/ngeo.js
(with content like ngeo.baseTemplateUrl = 'ngeo';) - the ngeo one-ring Angular module moves to
src/module.js
and is renamed"ngeo.module"
(this is the module currently required from all files and where we currently register angular components, directives, services, values). This is only transitory, it will be removed at the end of the migration. - the dist entrypoint is created in
src/distmodule.js
and is named"ngeo.distmodule"
it requires all top level Angular modules and extras and adds them to its dependencies. It is used to generatedist/ngeo.js
containing the entire library - each Angular file is wrapped in a dedicated Angular module which is stored in
exports
for goog.module or the symbol for goog.provide example for a component:goog.module('ngeo.mycomponent')
...exports = angular.module('ngeo.mycomponent', dependencies).component('ngeo.mycomponent', descr)
orgoog.provide('ngeo.mycomponent')
...ngeo.mycomponent = angular.module('ngeo.mycomponent', dependencies).component('ngeo.mycomponent', descr)
if the component requires some other service / partial, it should require them and add their modules as dependencies (use [] if no dependency) the created angular module is added as dependency to the "one-ring" module (with ngeo.module.dependencies.push(theModule.name)) - Angular files are grouped in Angular "top level" modules Example: the search top level module goog.requires the searchdirective (module) and adds it as dependency How to split the library in consistent toplevel modules is to be discussed with someone like Stéphane and Alexandre
- partials, services, ... are moved to the directory of their top level Angular module, there are no more "partials" or "services" directories
- Angular submodules goog.require their content and add them as dependencies: Some code may be very specific or requiring extra dependencies compared to the rest of the module. In that cases an extra module is created next to the toplevel module: example: search/extramodule.js where all these Angular files are added as dependencies.
Notes
Applications are expected to require toplevel Angular modules. When they require more they will also depend on individual pieces of code. During migration, the modules of Angular files are added as dependencies both to:
- the "one-ring" ngeo Angular module (legacy);
- its top level or extra module. At the end of the migration we will remove the "one-ring" module (and the associated goog.require and module.dependencies.push code)
How we split / build the code with webpack will be specified later (single build with chunks for gmf apps, examples?, dist...)
The transform to ES6 modules is automatic and has 2 steps:
- transform goog.provide to goog.module
- transform goog.module to ES6 modules. As a consequence, it is not a necessity to transform manually goog.provide to goog.modules