F
A couple of concrete things I’d address before merging:
-
noora/lib/noora/breadcrumbs.ex:124: the dropdown trigger is now an icon-only<button>with no accessible name. Previously the trigger contained the visible breadcrumb label, so screen readers had something to announce. We should add anaria-labelor visually hidden label for the switcher button. -
noora/lib/noora/icon.ex:63/noora/lib/noora/icon.ex:117:morphing_iconlooks like a general-purpose Noora icon primitive, but the implementation only seems safe for compatible filled-path icons. Some existing icons are stroked and/or multi-path, so using this broadly could render incorrect filled shapes. If this is intended for multiple dashboard interactions, I think we should make the support contract explicit or validate unsupported icons instead of letting them fail visually.
On the API shape: since this is planned for more than the breadcrumb selector, I’d prefer folding this into the existing .icon component rather than introducing a separate morphing_icon component. I would still keep animation opt-in rather than making morphing the default behavior.
For example:
<.icon name="check" />
<.icon
id="project-switcher-icon"
name="selector"
active_name="selector_2"
transition="morph"
watch="[data-part='trigger']"
active_state="open"
/>
Or even allow cheaper strategies for most UI cases:
<.icon name="selector" active_name="selector_2" transition="crossfade_rotate" />
<.icon name="selector" active_name="selector_2" transition="morph" />
That keeps .icon as the entrypoint, makes animation a first-class capability of icons, and lets Noora choose or validate the right strategy. We could also support transition="auto", where known-compatible pairs use morphing and everything else falls back to a crossfade/rotate transition.
So my take is: yes to a reusable primitive if there are multiple planned uses, but I’d make it a deliberate .icon API with an explicit transition strategy and compatibility checks rather than a general morphing_icon helper.
