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).