GSoC 2023: Next Generation Implementer Tools for OpenMRS 3

Community GSoC
,
1

Hey there, having participated once as a GSoC 2021 intern patching security issues,, I am interested to further learn about the OpenMRS Microfrontends by participating as a GSoC 2023 intern working on GSoC 2023: Next Generation Implementer Tools for OpenMRS 3.
This will bless me with a stronger skill set because it even directly involves tweaking the core of o3.

Objectives

Completing Priority: Must issues on the project plan. (simple and specific)

I think it will do alot of good if a chronological order is followed with regards to which task should be worked on fast. I think Must /Easy, should be completed fast, then Must/Medium and finally Must/Hard. As this will ensure that the intern warm up the intern, making him/her prepared for harder issues, tasks sharing similar components should be worked on subsequently because there is a higher chance to move faster.

I have opened this for sharing information with mentors and interested interns and community members.

cc @vasharma05 @hadijah315

1 Like
2

Basing on the fact that the scope is well defined and very clear, i think the entry-point should be changing the styling and the basic arrangement of of the Implementor tools, to display the toolbar on the top-left, create an arrow-down button to toggle implementor tools view, and change the general implementor tools to a dark background. This will solve some of the marked Easy tasks in the project plan.

However, i think we should re-think about how we open the portal to display the implementor tools because i realised that elements rendered on top of the widget don’t register event listeners.

By this i mean that if the portal is open and i render the a button on top of any widget, clicking that button should trigger a click event on both the button on the underlying element.
However, basing on my interaction with the current Implementor tools through [O3-512] Click slot name to find it in the Implementer Tools - OpenMRS Issues (feat: O3-512: clicking a slot name focuses the corresponding module config by jnsereko · Pull Request #634 · openmrs/openmrs-esm-core · GitHub) the event on the portal is not registered.

This means that we are going to have trouble with handling click events on our rendered buttons in the new designs in implementor tools

cc @vasharma05 @dkigen @hadijah315 @ibacher

1 Like
3

The problem could be with how the elements are added to the portal.

element = document.querySelector(
    `*[data-extension-slot-name="${slotName}"][data-extension-slot-module-name="${slotInfo.moduleName}"]`
)

Using homepage-widgets-slot as an example, the current implementation tries to get element with the following attributes.

data-extension-slot-name="homepage-widgets-slot" data-extension-slot-module-name="@openmrs/esm-home-app"

If i append a button as a child to this portal, it has to be clickable together with the underlying elements. Actually, this button is visible to the user but invisible to events like click, hoover, focus.

Could anyone have information why this is behaving as so?

4

Probably a good idea to review this: https://reactjs.org/docs/portals.html#event-bubbling-through-portals. (The el property tells React which element the portal applies to; it’s just a selector).

5

I have explored different options of how we can bring the ui design for the new implementer tools to life and i think i am narrowing down to 2 options.

  1. Thanks to @vasharma05, we can create an Iframe.

    To keep the iframe intensive, we shall embrace useMemo hook preventing it from reloading on multiple rendering. We shall also need to give the iframe maximum width, height and position it relatively so that it appears on top of he currently displayed esm-app. Displaying this might me hard, so we might just find means of preventing the currently displayed esm-app like when at home, esm-home and when at patient-chart, esm-patient-chart from rendering ideally, display: none

    We shall need to prevent the implementer tools form appearing in the iframe otherwise we shall have a loop, breaking the UI. We can do this by like disabling implementer tools in the iframe, ie all element nodes with <div id="single-spa-application:@openmrs/esm-implementer-tools-app-page-*"

    Approach

    • Either pass the current html node via the srcdoc property or the current current page via the src property like;
     const iframe = document.createElement("iframe");
     iframe.srcdoc = document.documentElement.outerHTML; # passing html-node  
     iframe.src = window.location.href; # passing current page

  1. Force the UI using css

    I have already used css to create the desktop view of the new implementer tools and I also think that the tablet view of this is can also be created. However, we shall need to position elements manually each time the implementer tools is open. We can setup a listener each time the implementer tools is open and apply some styling depending on the screen size so bring out either the desktop or the tablet view.

Since we can pass states from the window to the iframe, and at the same time it can manage its state, i think we can easily bring out both views properly with little tweaks. I would personally prefer using Iframe but both approaches require some tweak.

Current Appearance implementer-tools_AdobeExpress

What approach should be best @vasharma05 @bistenes @ibacher @dkigen @hadijah315? I am also so open to better suggestions so as to bring out this with least complexity but with a good performance.

cc @grace

6

The iframe option would certainly be cleaner as long as it has the following characteristics:

  1. The app state remains the same when the implementer tools are loading, other than necessary adjustments for screen size.
  2. The user is still able to interact with the application with the implementer tools open.
  3. When closing the implementer tools, the state of the application should not change other than resizing.

If we can meet those requirements, the iframe technique should work. That said, the real thing you should be pursuing is “whatever gets this feature working”… there are a lot of improvements we can and should make to the implementer tools.

7

here is the first 60% working prototype refactor: implement the new design for implementer tools by jnsereko · Pull Request #727 · openmrs/openmrs-esm-core · GitHub

1 Like