O3: Can we move to ONE Form Engine?

Development
, ,
1

Vision:

We now have 1 Form Builder. Imagine if we just had 1 Form Engine that was friendly to maintain together, with a shared roadmap.

Situation:

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)

Challenges:

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.

Next Steps:

  • 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 @Mekom 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 @Mekom 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)

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

4 Likes
2

Not as part of 3.0.0 anymore, but perhaps for 3.1.0 or beyond, see below.

The main reason why Mekom wasn’t initially supportive of developing a new React form engine was precisely because there was one that already existed with many features and that had been used in production for years at AMPATH.

The second reason was that this seemed like focusing on extra work when we simply needed O3 to work, again at a time where an existing AMPATH form engine was readily available to be included in O3.

Of course React would have been nicer, there is no discussion about this, I’m not challenging this specific point.

Integrating AMPATH forms was also the proof that our microfrontends framework could be of use for seamlessly mixing all the React of O3 with another JS framework (Angular).

So we collectively decided to Carbonise AMPATH forms instead, which was a pretty low hanging fruit to grab to have a whole form engine ready to be used.

Mekom has no resources to address the decommissioning of AMPATH forms until we have a full 3.0.0 release of O3 out there (see Releasing O3 Ref App 3.0.0-beta). Then, at that point, we could help move this goal forward as part of an upcoming 3.1.0 or 3.2.0 if other consumers of AMPATH forms are also ready to support this effort (cc: @jesplana, @jdick, etc) and are on board as well.

2 Likes
3

Yeah, moving forward, this is really mainly a case of needing resourcing - people - to do this.

@aojwang you made a good point to me recently that we’ll need to support custom implementation overrides. FWIW, @ibacher was explaining to me today that the work done to handle this in the Angular engine right now is not angular specific, e.g. the i18n. He has the Angular design mocked out in his head for the Angular Form Engine and expects it wouldn’t be hard to port that design to a React Form Engine. Supporting support custom functions local to an implementation (e.g. extensions that may not be available yet in the engine) wouldn’t be hard so long as we have defined data structures to handle that.

4

Just a small correction, the customisation of things (data sources, custom helpers) is not Angular-specific. The i18n stuff, however, is bit more tightly coupled to the AMPATH form engine implementation.

1 Like
5

I would add “Mappings First” to the list of critical features. It’s imperative that our forms tooling default to referring to concepts by mappings. Surely, referencing to concepts by UUID can & should be supported, but any real world use of forms beyond a single implementation – especially if we want to have any hope of sharing forms – will rely on referencing concepts by mappings instead of UUID. Two or more sites will not be able to use the same form if they’re concept dictionaries differ (as is almost always the case).

Hopefully, things are already working with referencing concepts by mappings. If not, we really need to ensure this is done.

Do we have the form schema documented in a repo (i.e., somewhere where pull requests could be made)?

3 Likes