Spike: Web modularity

Owned by Josh Zamor
Last updated: Apr 14, 2016
3 min read

Date:  Apr 2016

Problem

Determine how the 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.

 

Guidelines:

  • output should inform the v3 estimation process
  • modularity to minimize forking for front-end components
  • should not prevent offline usage - assume that this would be very useful for reducing forking in workflow-oriented processes
  • is more fine grained than page-level modularity where the page/screen can simply be thought of as separate sections that don't know much about one another
  • shouldn't adversely effect test-ability (E2E) or debug-ability.
  • connectivity implications should be noted
  • potential for re-using existing AngularJS 1 could lead to a better estimate

 

Results

This problem is broken down into 2 main parts:  separating the UI into multiple git repositories and allowing for functionality (e.g. calculation, view, etc) to be wired into another.

 

  1. 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. 
  2. Functional modularity
    1. 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.
    2. ECMA 5 supports modularity in a couple ways, however most seem to have rallied around AMD (Asynchronous Modular Definition) 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).
    3. 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

 

Depending on the results of the spike for re-using front-end code from an interface perspective, there appears to be a potential that much of the current AngularJS 1 code could be separated into multiple git repositories using Bower and NPM, and modularized by re-writing certain functions to be injected into a module which was loaded by RequireJS.  e.g. the requisition module might define a dependency of needing a requisition template which defined the columns of the requisition as well as business logic (such as calculate order quantity).  RequireJS could then load a requisition template module which defined how the columns within a requisition looked and worked.  AngularJS 1 with RequireJS are said to be fully testable (E2E w/ Protractor) and not to adversely effect debug-ability.

 

This spike hasn't yet delved into creating a PoC to test this nor has it answered the following questions: 

  • 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 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

http://bower.io/

Using RequireJS in AngularJS Applications:  http://www.sitepoint.com/using-requirejs-angularjs-applications/

http://requirejs.org/

https://docs.angularjs.org/api/ng/function/angular.module

http://weblogs.asp.net/dwahlin/dynamically-loading-controllers-and-views-with-angularjs-and-requirejs

AngularJS Modularization (we're modular already):  https://www.safaribooksonline.com/blog/2014/03/27/13-step-guide-angularjs-modularization/

 



OpenLMIS: the global initiative for powerful LMIS software