1433: Add support for sl-popup "virtualAnchor"

[grokwich]

This is by no means complete, but i wanted to get this in front of you Cory (and others) to get feedback.

Btw, build.watch() was not working for me until i made the change noted in the diff?

Cory, i know you felt like adding a new "virtualAnchor" property would be best, but the Float-UI anchor-element type is already a union of a real element + virtualElement.

export type ReferenceElement = Element | VirtualElement;

Also, it should not really be allowed to set both the "anchor" and "virtualAnchor" properties. We avoid that possibility if we just overloaded the "anchor" property to accept a VirtualElement.

Instead of aliasing the Float-UI VirtualElement type, i just used the Dom return type of getBoundingClientRect() : DOMRect
https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect

export interface VirtualElement {
  getBoundingClientRect: () => DOMRect;
}

DOMRect feels like a more portable.

I also limited the VirtualElement type to just the getBoundingClientRect() call. The other Float-UI VirtualElement members are optional and seemed to be pretty specialized scenarios, so i figured that starting here would give us the core meat, and you can always expand SLPopup.VirtualElement as a future enhancement.

Let me know what you think?

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
shoelace	✅ Ready (Inspect)	Visit Preview	Jul 11, 2023 2:44am

[claviska]

Cory, i know you felt like adding a new "virtualAnchor" property would be best, but the Float-UI anchor-element type is already a union of a real element + virtualElement.

Yep, after looking at the PR, a separate property does feel kinda weird. Feel free to merge it all into anchor.

I'd love to see an example in the docs for this. Probably something similar to what Floating UI has with it following the mouse cursor. I'm more than happy to provide that if you don't want to.

Looking forward to this one!

[KonnorRogers]

This is super cool! Agreed with @claviska in that I'd expect it to all just be under "anchor"

Is there ever a case where you would use both an anchor and a virtual anchor??

[claviska]

Is there ever a case where you would use both an anchor and a virtual anchor?

That was my [poor] suggestion from early on. In hindsight, it makes sense to keep it all under anchor. AFAIK, you can't attach more than one anchor in Floating UI anyways. My initial reservation was about types, but it actually seems much simpler the way @grokwich has proposed it.

[claviska]

Hey @grokwich! I noticed you merged the properties into anchor. Thanks for that!

Are you still working on this PR, or did you want us to take it from here, review it, and update the docs/changelog?

[grokwich]

Hello @claviska and crew. Here is a little prototype that demo's the latest code in the branch...

https://codepen.io/marko333/pen/JjeOzvJ/9b72ce661ccd024cfd0578460c180a6f

The popup appears anywhere the mouse is clicked. I was getting some FOUC on the initial render of the inactive popup, but i applied your :not(:defined) trick, which is working well.

I set shift shift-padding="10" on the the popup with the cool result of allowing the arrow to move appropriately on the popup to stay aligned with the mouseclick - even when clicked close the edge of the viewport.

A couple of issues to think about...

1. Are there scenarios where someone would want to apply a virtual anchor on a plain html page (not component) to set the initial location of the popup? Currently there is no serialized representation of a VirtualElement that can be set on the anchor as a String attribute. Maybe that's not a big deal and the standard pattern would be to init the popup in-active, then use javascript to set the anchor, then activate? If so, then i think is not an issue.

2. I set the popup strategy="fixed". Otherwise you will see that the page can scroll up indefinitely (presumably since the 'absolute' default is leaving the popup in the doc flow. There may be a corner case that requires the current default of strategy="absolute", but my guess is that vast majority of the time, expected behavior for the VirtualElement case would be strategy="fixed" (and absolute behavior would likely be surprising). If this is an issue, then one possible suggestion is that the default value for strategy remains as-is for all cases (backwards compatible), except when the anchor is a VirtualElement. In that case the default value could be fixed?

Feel free to take over, or if there is anything else you would like me to do, i am willing. You may want to at least take the doc work, just to ensure it's consistent with the great work done upto now (love the doc btw!-).

Thx

[claviska]

Thanks for your work on this! A subsequent PR including these changes plus documentation has been created in #1449.