Confirmed users
401
edits
Gaia/System/Refactoring Plan: Difference between revisions
Jump to navigation
Jump to search
Gaia/System/Refactoring Plan (view source)
Revision as of 05:49, 13 February 2014
, 13 February 2014no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
== Meta bug == | == Meta bug == | ||
http://bugzil.la/system-app-v2 | |||
== Target == | == Target == | ||
The main purposes/targets are: | The main purposes/targets are: | ||
1. To be ready for a module loader, no matter it's harmony or require. | 1. To be ready for a module loader, no matter it's harmony or require. | ||
2. To figure out the dependency and unnecessary coupling | 2. To figure out the dependency and unnecessary coupling | ||
| Line 11: | Line 12: | ||
6. To be more friendly to be contributed. | 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. | 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: | The stage’s target is to make sure we could have the following pattern: | ||
| Line 30: | Line 31: | ||
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. | 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 | 1. Find out loading sequence and dependency relationships | ||
2. Do architecture review and rework case by case. | 2. Do architecture review and rework case by case. | ||
Some candidate bugs for this stage | * Find the unnecessary module coupling and remove it. | ||
* Split a single "heavy-loading" module into different modules with its specific responsibility | |||
For instance, split window manager into 3 pieces: manager, factory, and classes. | |||
* Move the static DOM elements into its responsible module and let the module render its own UI with whatever template engine. | |||
* (optional) Use event emitter to replace DOM elements. (But we need to find out 'home' event replacement.) | |||
* Find out patterns and figure out if we could group them. | |||
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 | 1. Clean widget-like cost control | ||
2. Clean rocketbar | 2. Clean rocketbar | ||
| Line 49: | Line 52: | ||
6. Keyboard management 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. | 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. | 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! | 3. Do whatever you want - system should be stable enough now! | ||