Gaia/System/Refactoring Plan

Meta bug

http://bugzil.la/system-app-v2

Target

The main purposes/targets are:

1. To be ready for a module loader, no matter it's harmony or require.
2. To figure out the dependency and unnecessary coupling
3. To document well by jsdoc. [SYSTEM-JSDOC] http://alivedise.github.io/gaia-system-jsdoc/
4. To fit unit test well.
5. To have scalability for different target devices like tablet, TV, or even PC.
6. To be more friendly to be contributed.

Stage.1 - Painless instantiation

Rewrite all modules to be instantiable and rewrite unit tests, as well as jsdoc.

The stage’s target is to make sure we could have the following pattern:

// in bootstrap.js (main function, one line only expected.)
new System();

// in system.js
this.appWindowFactory = new AppWindowFactory(this);
this.appWindowManager = new AppWindowManager(this);
this.screenManager = new ScreenManager(this);

With this pattern we are able to do unit test anywhere, and there’s no architecture design involved in this stage. Even a new employee could take one of the modules to rewrite it correctly.

I'd already filed bugs (87 bugs, excluding downloadmananger and fxaccounts for now. Take as you like!) of this stage for every js under the system app. See meta bug.

Stage.2 - Architecture love

1. Find out loading sequence and dependency relationships
2. Do architecture review and rework case by case.
   1. Find the unnecessary module coupling and remove it.
   2. Split a single "heavy-loading" module into different modules with its specific responsibility
      1. For instance, split window manager into 3 pieces: manager, factory, and classes.
   3. Move the static DOM elements into its responsible module and let the module render its own UI with whatever template engine.
   4. (optional) Use event emitter to replace DOM elements. (But we need to find out 'home' event replacement.)
   5. Find out patterns and figure out if we could group them.
      1. For example many modules are depending on a specific settings to be ON/OFF. Maybe we could lazy load them in a SettingsOberver.

Some candidate bugs for this stage:

1. Clean widget-like cost control
2. Clean rocketbar
3. Manage hardware dependent modules together by feature detection
4. Split lockscreen
5. TrustedUI rework
6. Keyboard management rework

Stage.3 - Do experiments

1. We could start trying to load everything inside iframe as Vivien's lovely-proposal because we had the similar interfaces for modules now.
2. We could introduce module loader solution in this stage. I personally isn't the fan of any of them so I don't insist on this item is must-have.
3. Do whatever you want - system should be stable enough now!