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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

✨ <Menu /> support static option for Items #128

Merged

Conversation

aoifehannigan
Copy link
Contributor

@aoifehannigan aoifehannigan commented Jan 13, 2022

This PR add support for the static option in the MenuItems component which is used to determine whether the element should ignore the internally managed open/closed state.

Prop: static
Type: Boolean
Default: false

@@ -1,5 +1,5 @@
{{! template-lint-disable no-down-event-binding }}
{{#if @isOpen}}
{{#if (or @isOpen @static)}}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need @static? I really don't like over-expanding public API, and it seems just setting @isOpen={{true}} would be sufficient?

Copy link
Contributor

@bertdeblock bertdeblock Jan 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems the other implementations support a static option as well. So I assume, that's why the PR has been made.

Copy link
Contributor Author

@aoifehannigan aoifehannigan Jan 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I included the addition of the static option as it is supported in the React & Vue implementations and is already available in the ListBoxOptions component

In terms of a use case we will be using multiple Menus in a left nav and we need don't require the dropdown to close when focus is lost, only if the user has clicked to close the Menu, or another Menu has been opened. Utilising the static option to override the behavior in our app seemed like the best way to achieve this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding use case:
Somewhere in react doc, I saw information that might be useful for handling with own transition and animation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right it's here thank you!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the advantage over using isOpen though? I'm confused. Are the semantics really that much better even though the arg does the exact same thing?
Is there a difference in the other implementation?
🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm I think that <Menu.Items/> does not expect to receive isOpen prop. It is in template because is passed down from <Menu/> component, but intention was to not override this prop.
Here

By default, your Menu.Items instance will be shown/hidden automatically based on the internal open state tracked within the Menu component itself.

Probably it is possible to do it without static arg, but then the question is how far we want to be from original API in react and vue

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah! so @isOpen is actually private api.

I think perhaps I need to document the public/private ness of all the args 😅

@NullVoxPopuli
Copy link
Collaborator

Hello!!! thank you for your contribution ✨ ❤️
Just one question -- which which I can be persuaded for -- I just don't understand the use case atm. 😅

@aoifehannigan aoifehannigan marked this pull request as ready for review January 14, 2022 14:30
@aoifehannigan aoifehannigan force-pushed the dropdown-support-static-option branch from 82a5243 to 6bc98a4 Compare January 17, 2022 13:00
@NullVoxPopuli
Copy link
Collaborator

I guess the api to menu is already pretty small.
My main concern is eventual api bloat as she many ui libraries tend to have (8+ args, etc)

If we can keep that in check, and diverge from the other implementations if we need to, I'm ok with this change.

I mostly want to protect our users if react or vue libraries go off the rails.

@NullVoxPopuli
Copy link
Collaborator

Thanks for doing this!!! <3
Sorry it took so long to get merged -- I'll get this released shortly

@NullVoxPopuli NullVoxPopuli merged commit fe49e30 into GavinJoyce:master Jan 17, 2022
@NullVoxPopuli NullVoxPopuli added the enhancement New feature or request label Jan 17, 2022
@NullVoxPopuli
Copy link
Collaborator

Released in 0.12

@aoifehannigan
Copy link
Contributor Author

Thank you @NullVoxPopuli and @far-fetched!

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.

4 participants