As the Malawi implementation has progressed, we have started to realize that our UI extension strategy is not working perfectly. The Seattle team has started a discussion about this; we wanted to summarize where we are so far and get a wider comment from the community before continuing.
– Overview of OpenLMIS-UI Architecture —
As a reference, you can see the current UI extension documentation here , but a brief outline is that the OpenLMIS-UI is made up of different sets of docker images that expose UI files. These files are merged together, and files with the same relative file path overwrite each other. There are designs a tickets for deeper extension mechanisms, but they have yet to be implemented.
The original goal of this architecture was to allow easy ways for an implementer to completely remove and change the behavior of OpenLMIS-UI components and or pages. The original unit tests for a component are unable to be overridden, maintaining the component’s contract with other pieces of OpenLMIS.
**-- end OpenLMIS-UI Architecture – **
The issue is every time an implementer overrides an OpenLMIS-UI file, there is almost an unknown amount of tech debt the implementer is taking on — as there isn’t a clear way to tell if a new version of the underlying modules have made changes to these files.
(1) Some unit tests for services don’t allow for new object properties to be added dynamically with an AngularJS decorator
(2) A single HTML page can be a large amount of functionality to fork. We have plans to make extension mechanisms for these files, but there is lots of other work that is higher priority.
- A counter argument here is that HTML is really used only for displaying content not creating behavior
(3) Making pull requests back to main OpenLMIS-UI repositories currently requires copying and pasting work from the UI-distro it was developed and making a new branch on the OpenLMIS repository — this removes any history from the changes, and makes it harder to tell where specific contributions have come from
– nick –