💡 Proposal - dropdown refactoring

Forma 36 contribution proposal

The problem

At the moment we have variety of implementation with dropdown within different apps. They are not consistent, do not pass a11y rules, and hard to maintain because of custom complex logic. The list of examples of current Dropdown usage:

1. Two places where we create custom MultiSelect component based on Dropdown:
   • first
   • second

1. Two places where we changing default click event as a trigger to hover:
   • first,
   • second

1. Several places where we use DropdownList without Dropdown, and CardActions without Card components:
   • first
   • second
   • third
   • fourth

1. Places where we use Dropdown as a select:
   • first
   • second as a Timepicker with input as a trigger elem
   • third as a Timepicker in Launch

1. There are some places where we can put all sort of content inside dropdown:
   • Table with a TableCell to trigger an action
   • second with text and simple Buttons

Other interesting things:

1. In 90% of the use cases we repeat the same simple logic to open/close a dropdown when triggerElem clicked. Sometimes there are additional callback passed, like here. Maybe it’s worth to make component uncontrolled by default?

2. Place where we use span as a trigger element: span

The proposed solution

1. Do a base component, Dropdown or Popover (popover is a more common name based on other popular components libraries).

   • Component should be also exposed, since it will be used as a one for a custom content. So it will just trap focus inside dropdown, when it’s opened, and use default tab navigation within its content (focusTrapping should be optional prop).
   • Trigger element should be wrapped and passed as one of the children, not as a prop. It will introduce more flexibility for the trigger element and we will not have such cases, when the props that we pass on toggleElement end up on the wrong element. Example:

   // current
   <Dropdown toggleElement={<Button>Toggle<Button/>}>
   <DropdownContent>{...}</DropdownContent>
   </Dropdown>
   
   // new proposal
   <Dropdown>
   <DropdownTrigger><Button>Toggle<Button/><DropdownTrigger/>
   
   <DropdownContent>{...}</DropdownContent>
   </Dropdown>
   

   • Component will use https://popper.js.org/ as our current implementation.

2. Based on prev basic component we will create more specific one:

   • Autocomplete. Refactor the current one to make it follow a11y combobox rules. I’d propose to use https://www.downshift-js.com/use-combobox in order to not spend too much time on it.
   • Menu which will cover 70% percent of use cases. With correct a11y and clear usage guide. This component will cover two most common cases: as a navigation menu and as an actions manu.
   • Multiselect. We can also use downshift. Or create smth simple on our own.

3. I would argue that we need also Select component based on Dropdown. With clear design/usage guidance. We will probably use mostly Menu component or our native Select (from forms elements).

4. Make Menu component uncontrolled by default. So no need to repeat the same logic of togling by click. And also less temptation to introduce some custom logic, like open on hover.

5. For Menu and Autocomplete (and Select if we decided to do it) components make default behaviour where dropdown close itself when option clicked/chosen. Since it’s a recommended behaviour by w3c and I already found this approach in couple of places in our codebase example

6. If it possible, we can also expose the logic with keyboard navigation through menu items as a hook. So when someone needs to do some very custom menu they can use raw Dropdown and our hook for custom menu list.

7. Since I didn’t find any usage of dropdown nested menus in out projects, I think we can drop support of it.

Additionally

We also have some inconvenient behaviour with dropdown in the iframe. For example when we use dropdown in our entry field iframe, the iframe does not adapt to the open dropdown height. So I propose to add specific data attribute on our dropdown and add this code to updateHeight method. We can also add this attribute for others absolute positioned element that we want to be counted. So it’s not limited only to the dropdowns.

---

SO WDYT? 🤔

[thebesson]

Thanks, @bgutsol, I understand now! You are right, I agree on this one too.

[bgutsol]

awesome, very in-depth research! I have one question regarding this point:

1. I would argue that we need also Select component based on Dropdown. With clear design/usage guidance. We will probably use mostly Menu component or our native Select (from forms elements).

It is a bit unclear for me from the wording, do you propose to just make a Select based on this base component Popover and also keep native select from form components?

Thanks @thebesson

Sorry for the bad wording. I meant that that we probably don’t have to create a Select component that will be based on the popover. Because the cases that we have in the 4th example can be covered with Menu component or with our native select from form components. As @gui-santos said it’s just the matter of better guidelines and documentation.