User:JDrewniak (WMF)/notes/Close thyself - Managing MF Overlays

Who show/hides what? When? There are overlays, and there is OverlayManager, and there are also Drawers. Sometimes Overlays show/hide themselves, sometimes OverlayManager hides them. Drawers manage themselves.

Overlay
Overlays manage their own DOM structure, (i.e. everything inside the overlay, ). They also manage their own DOM events and a few window events as well.

DOM managed by Overlay
refers to the Overlay.





The bits that touch the actual document DOM are  and. These are executed in the Overlay show/hide methods.

OverlayManager
Manages overlays based on routing and keeps track of open overlays.

DOM managed by OverlayManager
Before this patch, OverlayManager did not manage any DOM directly, instead, it called Overlay.show/hide based on routing events.

Now OverlayManager accepts an  and attaches the Overlay to the DOM in the   method, but does not detach the overlay in the   method.

This means that currently Overlays cannot attach themselves to the DOM. This breaks loadingOverlays in rlModuleLoader, which calls Overlay.show.

In both before/after that patch, the following code produces a “ghost overlay”. In console:

This is because when one overlay calls hide, it removes the  class from the HTML element, regardless of other open overlays.

Given this problem


 * Should OverlayManager append the  class to the HTML element, instead of having Overlay do it?
 * Should OverlayManager detach the Overlay from the DOM as well?
 * Should Drawers have their own manager? Which does the same thing as OverlayManager just without routing?
 * Can OverlayManager be refactored for both cases?

Open questions:

“When does an overlay not use a route?“

-&gt; in rlModuleLoader, loadingOverlay.show/hide is called manually. Anything that calls  and returns a loadingOverlay, calls   on that overlay before showing the new overlay.


 * Categories overlay
 * VE overlay
 * Language overlay
 * Nearby

All these modules call. For this reason, moving the DOM ‘detach’ behaviour to the OverlayManager would require refactoring these modules to use the overlayManager. In these instances however, the overlays are all shown through the OverlayManager.