...
Data Resources & Domain Objects
As of OpenLMIS v3.2.1, the data that is used within the Currently the OpenLMIS-UI implements logic that is structured around resourceServices that closely map to OpenLMIS Services which . This has lead to repeated code with complicated methods. What has become clear is that the data used within OpenLMIS needs to be represented in classes, rather than objects that represent a requisition (for instance).
Another issue with many resource layers is that they are created as an AngularJS service, and these services are persisted in the browser memory until the browser is refreshed. Services can very easily cause memory leaks, and should be avoided.
To fix these issues we are going to take two organizational approaches:
- Data resource factories
- Follow DDD and make all returned resources be classes that are Domain Objects
NOTE: This actually maps to AngularJS's implementation of ngResourceJavascript objects recieved from an OpenLMIS Service are directly passed to route and component level modules, which makes reasoning about the current behavior of a screen difficult. There are many cases where implementation logic is difficult to follow because of how objects are mutated and passed between services.
This v7 architecture improves the OpenLMIS-UI by implementing patterns to aid code reuse and reasoning. ES6 and functional programming approaches in javascript focus on immutable data, which makes reasoning about the current state of a page easier and is more performant in web browsers. Using ES6's modular syntax will allow the UI to avoid global singletons when implementing business logic, which will help both unit testing and code reuse.
To structure this overall approach, the OpenLMIS-UI will use a paradigm that was popularized with the AngularJS module ngResource. The ngResource pattern allows for a "data resource" to be created as a singleton, which will then return objects that use the domain language to express changes to an object's state.
Data Resource Factories
The ideal first step for any resource factory would be to establish and implement a local database. This change will help the OpenLMIS-UI better fit into the "offline-first" suite of products.
...
These are things that improve the OpenLMIS-UI experience, and include directive, components, and CSS.
Components
Components are popular these days.
Directives
Directives are damn useful for enriching content and workflows.
CSS
Route and data modules should never be allowed to add CSS styles. This could cause issues if one page is supposed to look or act different than another page, but having divergent designs per page makes a UI feel inconsistent (so we should avoid this).