UI Architecture and dev-ui v7


This epic is about re-defining OpenLMIS-UI architecture and updating tooling to support more effective UI development.


  • More resuable and maintainable code

  • Incorperate build process tooling to improve performance

  • Reduce tight-coupling to Angular v1.x to allow for future framework changes


  • Why version 7? We have already released dev-ui v6, and having v6 and v6.0.0 be different might be confusing.

  • This work doesn't include an visual UI enhancements or changes, and all work done in this epic should leave the OpenLMIS-UI looking and functioning the same

  • This is not meant to be a large refactor or rewrite, but an addition of architectural patterns. Iterating on existing work that doesn't follow these conventions will be done slowly and judiciously after this epic is complete.

Here is an overview of the general features we are adding, and their value to the process:

Dev-UI to Semantic Versioning
Getting the dev-ui into the CI/CD process and having it update on changes will make doing all other work easier. Additionally, changing the version number to 7.0.0-BETA will signal that larger changes will happen.


Pure Javascript
Web frameworks change often, so we should write as much of the OpenLMIS-UI using pure javascript objects (POJOs) as possible. This will protect some of the investment we are making in building the OpenLMIS-UI, as it will enable frameworks to change, without incurring a large rewrite.

Currently we are using AngularJS and Grunt for most of the OpenLMIS-UI, and both of these technologies are slowly being abandoned. Most likely these frameworks will not become completely obsolete anytime soon, but making these changes now will offer flexibility and protection.

Another benefit of making our code base "pure javascript" is that we can move towards a reusable codebase.

  • which is easier to maintain

  • will allow the javascript to be reused in other places, such as services (ie backend) and native applications (ie android)

We will support ES6 by using Webpack and Babel because this combination will help automate and support code splitting (which improves download and start up performance).


Application Structure
The OpenLMIS-UI before v7 was created without an explicit architecture - this was because of initial deadlines to make the UI functional - but development has reached a point that an explicit architecture is needed and the framework that AngularJS provides is too flexible.

Our development approach will focus on building the documentation for the v7 architecture first, and implementing the architecture features as 'thin' wrappers around existing AngularJS framework components. This will keep all existing code functional, and allow new features to be built with the new architecture.

Details and discussion of UI Architecture v7 are located here

NOTE: These changes don't include presentation changes to HTML or CSS.


  • openlmisService that wraps $http

    • This will replace openlmisUrlService

    • Value: Simplifies cleaning requests and responses for the OpenLMIS Services.

  • Application router

    • Value: Intentionally separates presentation logic from data logic for UI pages. This makes extension and maintenance easier, and will reduce repetitive code.

  • Document "data resource" facade pattern

Build Process
The following tickets are focused on simplifying the OpenLMIS-UI build process, and adding tooling to monitor and increase code quality.


  • Add UI to sonar

  • Add linters to build process

    • Value: Linters help prevent common syntax mistakes and help enforce code quality




Nick Reid






Epic Name

UI Architecture v7