Date: Apr 2016
Problem
Determine how modularitythe UI, especially within a specific functional area, may be modularized. For example if a requisition and it's associated template were modular back-end services where new columns could be added or a new suggested order quantity calculation could be plugged-in, then it follows that it would be useful to modularize the requisition screen so that it wouldn't have to be forked.
...
- Separating UI components into separate Git repositories seems to have a number of possible solutions. The current front-runner seems to be using Bower in conjunction with Grunt and NPM. An alternative could be Grunt with grunt-curl, which would be considerably lighter-weight but would miss out on any packaging or versioned dependency management. NPM could be used alone, for which it supports nested dependencies, however this heavy-weight approach isn't generally favored since a web-app wouldn't want modules to load their own JQuery (for example). Bower is lighter-weight, doesn't allow nested dependencies, and seems to be favored on the front end for this reason.
- Functional modularity
- is something that's coming in ECMA 6, however presently few browser's support ECMA 6, nor does it seem that we should assume that low-resources environments will have adoption of those browsers in 2017. A good timeline for browser support of ECMA 6 isn't well-known at present.
- ECMA 5 supports modularity in a couple ways, however most seem to have rallied around AMD (Asynchronous Modular Definition) and through RequireJS. RequireJS allows modules to be defined and can load them asynchronously while taking care of the load order. Using RequireJS with AngularJS 1 also seems to be well written about and they seem to naturally compliment one another (AngularJS has modules and handles dependency injection, RequireJS can define which module is loaded). AngularJS 2 also natively supports AMD (and so presumably you don't need RequireJS).
- Our current code is written in AngularJS 1 utilizing the built-in module support and so this suggests that a pre-modulartizaiton step isn't required.
Recommendations and Next Steps
...
- would this break app-cache for offline usage?
- would separate modules with separate RESTful endpoints greatly effect bandwidth in low resource areas?
It's recommended that a week long longer spike be done to verify the general approach outlined and determine LOE for modularizing a small piece of the v2 UI - dependent upon the results of the UI re-usability spike with regards to RESTful API design. Given that this level of modularity is certainly more work, it should be reserved for reducing forking in "heavier" workflow-oriented UI, and therefore this extended spike should not be needed as a further input to the current estimation exercise.
Resources
Using RequireJS in AngularJS Applications: http://www.sitepoint.com/using-requirejs-angularjs-applications/
https://docs.angularjs.org/api/ng/function/angular.module
AngularJS Modularization (we're modular already): https://www.safaribooksonline.com/blog/2014/03/27/13-step-guide-angularjs-modularization/