Page Comparison

...

As Bahmni evolves, we have started building modules in React instead of angularJsAngularJS. Currently, these react React components are built inside angularJs AngularJS applications using adapters. What this means is that every React-based module needs to be built with an angularJs AngularJS-based repository, adding to code duplication and maintenance overheads.

Additionally, any React module which needs to install its components within existing angularJs AngularJS modules of bahmniapps (e.g. the form-controls) will need to be build built along with openmrs-module-bahmniapps since angularJs AngularJS does not allow for dynamic dependencies. What this means is, that the bahmniapps project must be rebuilt for every deployment of such a react module.

...

WebPack supports a technique called Module Federation, through which it allows the use of dynamic javascript JavaScript modules which can be fetched at runtime. Coupled with React’s Suspense model, a React component can now use a component loaded from a remote javascript file at runtime. With this strategy, openmrs-module-bahmniapps can use react components served from a different web-server/container at runtime and these react components can reside in their own repositories with independent deployment strategies. The host UI of openmrs-module-bahmniapps does not need to be rebuild rebuilt to get the latest of these react components.

This solution also involves separating out the angularJs AngularJS adapter code into the openmrs-module-bahmniapps repository so that these dynamic react React modules do not need to be build built with any sort of angularjs AngularJS dependencies and can be set up as pure React projects.

...

1. openmrs-module-bahmniapps now contains a separate folder for the react micro-frontend source called /micro-frontends. Built files from this folder are written to ui/app/micro-frontends-dist/ folder so that the angularJs AngularJS applications can refer to them. These files are typically *.min.js and *.min.css.

2. Common code across all MFEs is handled as a unique entry point called shared which results in shared.min.js and shared.min.css files. This, along with react + react-dom files, needs to be loaded before loading any micro-frontend.

3. A local MFE is available called next-ui. This is meant to house react components which don’t need to have their own repositories. angularJs adapters over the main entry components results in an angularJs module called bahmni.mfe.nextUi which can be added as dependency to your angularJs module when you include next-ui.min.* files in your angualJs AngularJS entry. Since these components don’t have remotes, they will need to be built and updated along side openmrs-module-bahmniapps repository.

4. For remote MFEs, there is one repository each. These repositories will have exposed certain entry components through the ModuleFederationPlugin. Once these repositories are built and deployed, they will be serving a remoteEntry.js file which will be used for loading these remote components. Most likely, this web server would be proxied within the Bahmni proxy.

5. At bahmniapps/micro-frontends/ there will be one WebPack entry point for every remote micro-frontend.

   1. This will house angular adapter code for react components resulting in an angular module called bahmni.mfe.<name-of-entry>. This needs to be injected into the Bahmni module requiring this micro-frontend.

   2. The adapted react components will each lazily load corresponding remote react components using remotEntry.js at run time.

   3. These will be built as <name-of-entry>.min.js and <name-of-entry>.min.css which can be loaded by the Bahmni module requiring this micro-frontend.

...

1. ModuleFederationPlugin which allows WebPack to reference remote modules

2. Suspense techniques in react React which allows allow lazy loading of remote react React components

3. react2angular which adapts react components into angularJs components

...