Update: we have created an openmrs-rfc-frontend github repo where we’ll be tracking and documenting decisions about the future of OpenMRS frontend. Please jump in and comment on things, propose things, etc.
To address your questions, @paul:
I keep wondering if we can get to a place, where… given the high-level use case (I want to care for a patient, I want to build a patient cohort, I want to build a report, etc), whether we can have a standard set of page structures (ie, 3 boxes by 3 boxes with a top gutter for patient context), and then allow community developers to build the widgets for the boxes?
A good question and a tough one. Here’s a link to some related discussion and ideas. Layout components can be pretty tricky to manage, but also very valuable. I think the big question is how similar/dissimilar/flexible the UI is for different distributions. A component that tries to be flexible enough for anything but opinionated enough to be useful is really hard to do well.
One more quick question: in your slides, you refer to the smaller UI compositions as “single-spa applications”. Do those multiple applications which might comprise an end user page view all share the same data context?
Could you explain how you’re using the term data context? The applications all share the same javascript runtime environment, which includes the DOM, event loop, global variables, and global events. They are not isolated from each other via iframe. However, each can have its own variables in memory that are encapsulated and not accessible to any other application. API data is usually stored inside of encapsulated variables such as those, but can be shared if needed with other applications.