We now have 1 Form Builder. Imagine if we just had 1 Form Engine that was friendly to maintain together, with a shared roadmap.
Right now, we have 2 different Form Engines for O3:
- The Angular Form Engine (aka Ampath Form Engine)
- The React Form Engine (aka OHRI Form Engine)
A detailed breakdown of the two is provided here in this Form Engine Comparison: Form Engines_ Comparison.pdf (80.5 KB)
We, the OpenMRS community, now face several challenges:
- Complexity of maintaining both Angular + React solutions: When we do things in React-land, these are not always also done in Angular, and vice-versa. This adds complexity that we are already not keeping up with. Prioritizing addressing this will result in a product that is easier to maintain since we won’t run into headaches around how things differ between React and Angular.
- Sustainability: We already struggle to find devs comfortable enough with Angular to help us maintain or improve the Angular Form Engine (or even to review PRs). The frontend industry seems to prioritize React, and the vast majority of everything else in O3 is currently in React. A React-based engine would expand the pool of people able to help maintain the engine.
- Feature Imparity: Many things are not as complete as they should be. Even though folks have tried to use a similar schema, functionality is already breaking between the two. Having ONE engine would mean feature support could grow faster, with more team-efforts, than it can now.
Let’s have a public discussion on this on the TAC call next week, on Feb 2.
Possible approaches: The Angular Form Engine does have more features. So, we could take the features & lessons learned from Ampath and start incorporating those into the React Form Engine. (Actually the React Form Engine is already refactoring a few of the features in the Angular Form Engine.)
Critical Features to Refactor if we go Angular → React:
- I18n - @ICRC and @MekomSolutions have done significant recent work to make Ampath Forms localisable. This is a must-have in general for a sustainable OMRS forms engine.
- Schema Parity - Forms that currently load in the Angular Form Engine must continue to properly load in the React Form Engine. The React Engine uses the same schema, so once this Iniz/O3 issue is resolved (which @ibacher plans to do shortly), we don’t expect problems.
- Offline - @ICRC and @MekomSolutions also invested engineering effort to enable Angular Forms to be compatible in O3’s new Offline Mode. This is a big should-have to enable the EMR to handle unreliable network connections.
- Parity of custom components & data sources & expression helpers
- Reference Mappings instead of bespoke Concept UIDs (makes it possible to share forms at scale, across customized implementations)
- Critical Features to Refactor if we go Angular → React:
Resources for Feature Porting & Refactoring From Ang→React: The @UCSF team has already expressed a strong desire to convert the OHRI repo into a community-owned “OMRS Form Engine” repo. But we’ll need to get even more specific together: What eng resources are available? How many people are available to work on this?
We’re very keen to hear who might be interested.