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.
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
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
The problem could be with how the elements are added to the portal.
element = document.querySelector(
homepage-widgets-slot as an example, the current implementation tries to get element with the following attributes.
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?
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).
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.
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
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,
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
- 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
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.
What approach should be best @vasharma05 @bistenes @ibacher @dennis @hadijah315?
I am also so open to better suggestions so as to bring out this with least complexity but with a good performance.
iframe option would certainly be cleaner as long as it has the following characteristics:
- The app state remains the same when the implementer tools are loading, other than necessary adjustments for screen size.
- The user is still able to interact with the application with the implementer tools open.
- 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.