RFC: Advanced Dropdown menu shorthand

[jeffcarbs]

http://react.semantic-ui.com/modules/dropdown#search-in-menu

I'd like to use this variation of the dropdown in my app but we currently don't support it. I'm happy to take a stab at implementing it, but don't really have a good idea how it should work.

The issue is that the markup can become pretty complex, with variations on headers, dividers, the search box, options, etc. See this example for another variation: http://react.semantic-ui.com/modules/dropdown#input

It would be nice to give ultimate control to the user, but I'm struggling to see how that's possible since we need to know:

1. the options so that we can filter them. Currently we don't support options + children.
2. where the search box is so that we can

• detect change
• allow the searchQuery to be set as an auto-controlled prop (this isn't an autocontrolled prop now but I kinda think it should be. If it's too hard to do with search-in-menu we can forego it though.)

One kinda crazy idea is to allow the user to specify a "schema". Something like:

const nestedMenu: [
  { component: Dropdown.Header, content: 'Search Issues' },
  { component: Dropdown.Input, value: this.props.searchQuery },
  { component: Dropdown.Header, icon: 'tags', content: 'Filter by tag' },
  { component: Dropdown.Divider },
  { component: Dropdown.Menu }
]

<Dropdown options={options} nestedMenu={nestedMenu} />

Then we can parse out which is the search input, and which is the nested menu where we should render the options. We can validate the schema such that there's exactly one menu and at most one input (theoretically you can make a nested menu that's not searchable).

@levithomason @layershifter - would appreciate your thoughts!

[jeffcarbs]

@levithomason - any thoughts here? I think we're again faced with a similar issue as #893 (comment), where we want to give the user complete control of rendering while being able to listen for events emitted by those user-rendered components.

@davezuko - Since Levi mentioned you on that related comment, would love your thoughts as well.

[levithomason]

Sorry, haven't had the brain cycles this one needs. Giving it a little thought my intuition is that we provide shorthand for the most probable use case, for now. Something that adds the search and a callback when it is changed?

<Dropdown options={options} onSearchInMenuChange={} />

We could render a minimal search like so:

Shorthand Search In Menu Input

We could also allow passing your own search input shorthand:

<Dropdown 
  options={options} 
  searchInMenu={{ icon: 'tag', placeholder: 'Search tags...' }}
  onSearchInMenuChange={}
/>

[levithomason]

I'm running into several cases where I want to insert a Divider or Header into the options list. Starting with shorthand for the Menu (items) may be a good place to build up to the Search In-Menu variation as well.

Regarding the proposed component key solution, we already use this pattern in the FormField so I'm thinking it might make sense to make this a standard for shorthand. If there is a component prop, we will createElement(component, rest). Then, you can use any component you like.

Current factories assume all items in an array should create elements of some predefined Component (e.g. Dropdown.Item). A component key would allow you to override the component to create different elements. This is different than passing an element of another type since that would be cloned and merged rather than simply ignored in favor of a different component entirely.

If we did this, it would solve my use case as I could pass different menu item components without merging them with the Dropdown.Item. I think it gets us closer to solving the search in menu case as well.

[saitonakamura]

I've opened separate issue #1724 for divider and header shorthands

[itwasmattgregg]

Has anyone figured out the issue of arrow keys not working to access dropdown menus? I have a Dropdown.Menu inside a Menu.Menu.

[levithomason]

Yes, it is unsupported. Note the doc site alerts above all Dropdown examples that use subcomponents:

The subcomponent API will be removed in favor of shorthand only. When using props, we can add the listeners needed and regenerate children according to the Dropdown state.

There is no idiomatic React way to parse and manipulate children, therefore, if you use children then you need to manage the state yourself. Managing state of the Dropdown is not practical for developers to implement due to the complexity (there are over 2k lines in this component).

[hubertguillemain]

Can you please provide in the interim samples of options prop to replace Dropdown.Divider and
Dropdown.Header ?

[levithomason]

I don't have a need for this so I am unable to work on it. If this is a feature you need, a contribution would get reviews and merged ❤️ Just make sure it plays nicely with the currently open PR.

[alakhera]

Please let me know the Dropdown menu change event

[levithomason]

@alakhera please reserve GitHub for bugs and features. We have a dedicated Gitter room and StackOverflow tag for providing support. You'll get the best support there.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

[levithomason]

Thanks to @rijk, we have improved how we handle stale issues, see #2761. Reopening.

[stale]

There has been no activity in this thread for 90 days. While we care about every issue and we’d love to see this fixed, the core team’s time is limited so we have to focus our attention on the issues that are most pressing. Therefore, we will likely not be able to get to this one.

However, PRs for this issue will of course be accepted and welcome!

If there is no more activity in the next 90 days, this issue will be closed automatically for housekeeping. To prevent this, simply leave a reply here. Thanks!

[stale]

This issue will be closed due to lack of activity for 12 months. If you’d like this to be reopened, just leave a comment; we do monitor them!

[stale]

There has been no activity in this thread for 180 days. While we care about every issue and we’d love to see this fixed, the core team’s time is limited so we have to focus our attention on the issues that are most pressing. Therefore, we will likely not be able to get to this one.

However, PRs for this issue will of course be accepted and welcome!

If there is no more activity in the next 180 days, this issue will be closed automatically for housekeeping. To prevent this, simply leave a reply here. Thanks!