Patient Summary Widgets Sprint

Cool!

I see you mentioned Angular, but the patient summary is still implemented in old-school UI Framework, and the requirements for the widgets are that they’re packaged as “fragments” in the UI Framework.

I hope we can plan for a future where (a, sooner) we move away from UI Framework for the patient summary, and (b, later) we move away from Angular 1.x.

Ideally you would actually write the code for these widgets in a plain html+javascript project (and maybe even configure it in such a way that you can test and iterate on the widgets purely based on mocked calls to OpenMRS’s REST API)

Then in the coreapps module (or wherever) we use something like npm install to fetch the javascript, and just have a thin GSP wrapper that takes care of exposing the functionality as a fragment.

In fact, trying to think ahead, I propose that we change the section configuration parameters a bit from what @ssmusoke wrote in the wiki page. We should plan for a single “dashboard config json” which contains an array of widget configs. Each widget config should have a widgetUid (this replaces provider and fragmentId; I guess its value would be like “coreapps.latestObsForConceptList”). We don’t need order because the widgets are already in order in the array. We don’t need extensionId because that’s implied by the dashboard config json file.

If we go this way, the entire dashboard config needs to be somewhere directly admin-editable (I prefer the Bahmni approach of a config folder for the implementation, that can also be a source-controlled repo, but we could also store it in the DB). I.e. for configuring the dashboard we’d move away from the model where “various modules attach to the extension point, and the framework figures out the ordering” to a model where “user configures it directly”.

[This is not where I expected to end up when I started replying to the post. I was actually going to talk about planning for being able to support angular2 or react widgets in the future, and maybe planning for storing data in a shared redux store that multiple widgets could render from…and I haven’t even gotten there yet. :slight_smile: ]