...
Earlier, we distinguished between the cross-cutting concerns and the elementary UX elements. The latter should either be included in the app shell directly or indirectly via an import map. In any case they are assumed to be always there.
(tbd)Right now pretty much all of the widgets from openmrs-esm-patient-chart-widgets (https://github.com/openmrs/openmrs-esm-patient-chart-widgets/tree/master/src/widgets) should be considered for a dedicated microfrontend. Things like banner potentially distribute among all of the microfrontends.
- allergies
- appointments
- attachments
- conditions
- heightandweight
- location
- medications
- notes
- profile
- programs
- visit
- vitals
Also new widgets such as the immunization make perfect sense for distribution into a dedicated package (microfrontend).
Repositories
One possibility is to utilize a monorepo for combining certain parts:
...
The foundation that allows a much more flexible and modular system is an extension component ↔ extension slot mechanism. In general, this follows an event listener ↔ event emitter mechanism - just for components.
The idea is that a component may offer a place / places where additional - context-sensitive - functionality could be displayed. This is an extension slot.
Our extension slot should be capable of:
- defining a fallback if nothing would be shown otherwise
- restricting rendering to a defined number of components (e.g., only allow a single component)
- reordering based on configuration (implicitly handled; ordering key to be defined)
- allowing or banning extensions should also be implicit via the configuration (blocking key to be defined)
- lazy loading the component(s) filling the extension slot, without any need to know where (from what microfrontends) they are coming from
Extension slots pass in their configuration (see above), together with some parameters (context-sensitive), and (most importantly) the name of the extension slot. The name acts as an identifier to find the relevant extension components.
(tbd)