Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Menu #286

Merged
merged 20 commits into from Apr 18, 2024
Merged

Implement Menu #286

merged 20 commits into from Apr 18, 2024

Conversation

miguelcobain
Copy link
Contributor

@miguelcobain miguelcobain commented Apr 9, 2024

Opening the PR to gather initial feedback on the approach.
Currently opens/closes the popover with internal state.

@NullVoxPopuli is this initial approach what you expected?

Next step is yielding the Item and Separator components from Content.

I think a good first goal for the Menu would be an API like:

<Menu as |m|>
  <button type="button" {{m.trigger}}>Menu</button>

  <m.Content as |c|>
    <c.Item>Item 1</c.Item>
    <c.Item>Item 2</c.Item>
    <c.Separator />
    <c.Item>Item 3</c.Item>
  </m.Content>
</Menu>

Some questions I have:

  • should we allow passing in an @isOpen arg, to control the open state of the Menu from the outside?
  • if yes to the above, should we provide an accompanying @onToggle action?
  • in the proposed API, we discussed items and separators as components. Could it make sense to have them as modifiers instead? That would probably more freedom to the caller, no? 馃
  • <ComponentSignature @module="components/menu" @name="Signature" /> probably won't work because we're importing Args type from another file, right? (i.e Args: PopoverSignature['Args'];).
  • we should probably default @placement arg to 'bottom-start', since it's how most menus work like. Do you agree?

@NullVoxPopuli
Copy link
Contributor

NullVoxPopuli commented Apr 10, 2024

is this initial approach what you expected?

yes! this is looking fantastic!

should we allow passing in an @isopen arg, to control the open state of the Menu from the outside?

I can't think of a use case where we want to force a menu open 馃
if one comes up, there is no reason we can't add it later.

if yes to the above, should we provide an accompanying @onToggle action?

n/a

in the proposed API, we discussed items and separators as components. Could it make sense to have them as modifiers instead? That would probably more freedom to the caller, no? 馃

what would these modifiers do?

<ComponentSignature @module="components/menu" @name="Signature" /> probably won't work because we're importing Args type from another file, right? (i.e Args: PopoverSignature['Args'];).

I'm not sure -- if it ends up not working, we can just say "see Popover args" for now with a link -- the way I'm doing typedoc introspection is super weird, and I have an issue open with the maintainer to maybe one day have some help figuring stuff out 馃槄 github.com/TypeStrong/typedoc/issues/2528

we should probably default @placement arg to 'bottom-start', since it's how most menus work like. Do you agree?

I do, yes

@miguelcobain
Copy link
Contributor Author

miguelcobain commented Apr 10, 2024

what would these modifiers do?

They would be used to "register" items and separators. Example:

<Menu as |m|>
  <button type="button" {{m.trigger}}>Menu</button>

  <m.Content as |c|>
    <div {{c.item}}>Item 1</div
    <div {{c.item}}>Item 2</div
    <div {{c.separator}}></c.Item>
    <div {{c.item}}>Item 3</div
  </m.Content>
</Menu>

item and separator modifiers would add role="menuitem" and role="separator" respectively.
Now that I'm reading aria docs, it feels like using a modifier would get pretty difficult really fast with things like managing aria-disabled="true" on the items.

Now that I think about it, the trigger should also have aria-expanded="true|false", which is tricky to manage with just a trigger modifier. :/

@NullVoxPopuli
Copy link
Contributor

Ah yeah, more reason for components for the items and separators.

For the trigger modifier, it can still manage that aria attribute, 'cause i don't think we ever omit it?

@miguelcobain
Copy link
Contributor Author

For the trigger, there's also aria-expanded and aria-controls.
A trigger component would make things easier.

@miguelcobain
Copy link
Contributor Author

miguelcobain commented Apr 10, 2024

Another argument in favor is:

Any button that open a menu should have a role of button or, preferably, be a , and also have aria-haspopup="menu" (or true) set.

So, I think we shouldn't encourage the user to use any element at all, since it requires interactivity.
Plus, as mentioned before, a component allows us to manage more things for the user (aria-controls, aria-haspopup, aria-expanded, and probably other things in the future).

@miguelcobain miguelcobain changed the title Implement Menu (WIP) Implement Menu Apr 11, 2024
@miguelcobain
Copy link
Contributor Author

@NullVoxPopuli this PR is ready for review. 馃檹

@miguelcobain
Copy link
Contributor Author

@NullVoxPopuli feedback was applied

@miguelcobain
Copy link
Contributor Author

Dependent on CrowdStrike/ember-velcro#190

@NullVoxPopuli NullVoxPopuli merged commit 442d9e3 into universal-ember:main Apr 18, 2024
15 checks passed
@NullVoxPopuli NullVoxPopuli added the enhancement New feature or request label Apr 18, 2024
@github-actions github-actions bot mentioned this pull request Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants