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 @dennis @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).