Consolidate dropdowns

[ukutaht]

Changes

This only applies to Phoenix/Liveview frontend area.

1. We have a dropdown component which is currently only used on /sites page and nav header
2. This PR starts using the same component on settings people page as well, gets rid of the hand-rolled dropdown there
3. Moves more styling concerns from usage site to component itself.
   3.1 Menu is positioned automatically. This is overridden in nav header due to the trigger having very large padding
   3.2 Menu will size itself based on the width of its contents. Can be overridden with max-w-[x] and min-w-[x].
   3.3 Menu and items come with default styling now
   3.4 Adds disabled state to dropdown item, and a tailwind variant to be able to easily target it

Do we have any other hand-rolled dropdowns in the app that should be consolidated here?

Future possibilities:

• Create <.dropdown_button> component which will render a <.button>. Needs some work on the button component itself because buttons in general are quite varied.

[github-actions]

Preview environment👷🏼‍♀️🏗️
PR-4934

[aerosol]

Merged master to get 281f3ec in order for preview image to build 👀

[aerosol]

Impressive work jumping through all the hoops along the way 😀
All three dropdowns seem to work well.

Nitpicks below - feel free to ignore and merge as-is:

• There's a shaky glitch sometimes when hiding the dropdown by clicking away.

  record-2025-01-06-06-50-01-foci.ante.ever.mp4

• To hairsplit a bit: mixed feelings about the :button slot name, mostly because we have a button component - not sure I can come up with a better name, but maybe something like :toggler?

  • Similarly, maybe dropdown_item could be turned into an :item (or :option - to follow standard HTML select convention) slot, since it's never meant to be used outside of a dropdown? And following up on that, the divider could be controlled via :item's attribute?

[aerosol]

Do we have any other hand-rolled dropdowns in the app that should be consolidated here?

Not that I know of - the ComboBox itself is an incarnation of a dropdown, but I don't think we'd benefit from trying to consolidate it, given the existing complexity.

[ukutaht]

Thanks @aerosol

There's a shaky glitch sometimes when hiding the dropdown by clicking away.

Can't reproduce myself unfortunately. Can you try again with 0fd45da?

To hairsplit a bit: mixed feelings about the :button slot name, mostly because we have a button component

Yeah I agree something like trigger or toggle would make more sense at the moment. However my plan is to make it so that it renders an actual <.button> component in which case the name would make more sense. But for that I need to make sure the <.button> component is flexible enough to be used here first.

Similarly, maybe dropdown_item could be turned into an :item (or :option - to follow standard HTML select convention) slot, since it's never meant to be used outside of a dropdown?

I didn't find a way to render nested slots with Liveview (:item would be a child of :menu). Happy to incorporate it if you have a suggestion :)

[aerosol]

I didn't find a way to render nested slots with Liveview (:item would be a child of :menu). Happy to incorporate it if you have a suggestion :)

Ah 🤦‍♂️ - let's just not, this is great as is.

[aerosol]

Can you try again with 0fd45da?

Did try, same thing. Only on Firefox though.

[aerosol]

dark mode does not render properly