refactor(dropdown): extend updateComplete timing for overlay oven/close

[Westbrook]

Description

• allows sp-dropdown to lazy load the Overlay and sp-popover code
• wraps that laziness into the updateComplete lifecycle promise, so that timing-based interactions with the element can be managed with the appropriate fidelity

Motivation and Context

• users should be able to prevent unused code from being downloaded by their applications
• when doing so, those same users should be able to time interactions based on the availability of that code

How Has This Been Tested?

• updated unit tests
• manually build/test in westbrook/11ty

Types of changes

• refactor (update interface to render timing)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[andrewhatran]

I understand that we're lazy loading Overlay so that we can prevent unused code from being downloaded.

However, since every dropdown contains an overlay, wouldn't Overlay be imported every time a dropdown is used?

[Westbrook]

100%, Overlay is a hard requirement of using the functionality that is delivered by an sp-dropdown element. However, lazy loading isn't only about preventing unused code; that's more directly a responsibility of tree shaking and side effect management (see #679 that looks to enhance out approach to that).

In this case, Overlay isn't a requirement of displaying the dropdown element when closed, and if you don't need to interact with the dropdown, this would allow the page never to download that JS. As an example, checkout the documentation site: https://opensource.adobe.com/spectrum-web-components/ unless you specifically interact with the theme customization UI, or are looking to review the dropdown documentation, there is no need to load the Overlay scripts.

In the case that you do need the Overlay scripts, it is highly unlikely that you'd interact with the dropdown immediately (e.g. load the page with the dropdown open by default, an,. if needed, that can be managed into a single bundle externally). This change looks to ensure that we give download/parse/run priority to JS that is required as the page is rendered by moving this Overlay into the dynamic dependency graph as opposed to the static dependency graph.

[andrewhatran]

I see, that checks out. Giving priority to JS when the dependency is required rather than at construction makes a lot of sense.

It makes even more sense for disabled dropdowns.

[andrewhatran]

Looks good to me!