Button groups with (split) dropdown/up

[heruan]

Common UI variations of buttons are:

• button groups
• button dropdowns/dropups (optionally split)

For example in Bootstrap:

As shared with someone from the team I understand these should be somewhere on some roadmap, so I'm opening this to gather related discussion here.

[jouni]

Quick mockups for Lumo:

[heruan]

They look great! I imagine a source like this:

<vaadin-button>
  <span>Actions</span>
  <vaadin-button-dropdown>
    <vaadin-button>Action one</vaadin-button>
    <vaadin-button>Action two</vaadin-button>
    <vaadin-button>Action three</vaadin-button>
    <hr>
    <vaadin-button>Additional action</vaadin-button>
  </vaadin-button-dropdown>
</vaadin-button>

<vaadin-button-group>
  <vaadin-button>Action</vaadin-button>
  <vaadin-button theme="icon">
    <iron-icon icon="lumo:dropdown"></iron-icon>
    <vaadin-button-dropdown>
      <vaadin-button>Action one</vaadin-button>
      <vaadin-button>Action two</vaadin-button>
      <vaadin-button>Action three</vaadin-button>
      <hr>
      <vaadin-button>Additional action</vaadin-button>
    </vaadin-button-dropdown>
  </vaadin-button>
</vaadin-button-group>

Just tried to play with vaadin-context-menu to fiddle something like that, but it quickly gets cumbersome (e.g. alignment, device detector).

[jouni]

IMO we should reuse something like context-menu and vaadin-list-box here, so that we get keyboard navigation and other functionality for free. But we should first figure out a way to make something like a “vaadin-menu” element, which doesn’t always contain selectable items.

[jouni]

Not exactly sure which of these two issues is the main one.

This one here seems to have two use cases combined (maybe even three), while the referenced issue is just about grouping buttons visually (and perhaps about toggling the buttons on/off).

[heruan]

I'd consider this the main one, as it includes the same use case and it's already in the right repo 🙂

[heruan]

There is also vaadin/vaadin-select#92 which might be a duplicate of this. There you said there was a vaadin-menu-button component planned: is this still true, or the feature will be in vaadin-button?

This is quite a blocker migrating from FW8 MenuBar, which I guess was used by many not as a real menu bar but more a dropdown button 🙂

[jouni]

To be honest, I’m not completely sure how the pieces will fall into place. But I’m quite sure we want to offer an explicit component for this use case, something like <vaadin-menu-button>. I don’t think this will be part of the select component, as the use case is different (a form field vs a navigation element).

And we’ve heard so much feedback about MenuBar, that it’s one of the priorities in our “bridging the gap” project (to make it possible for everyone to migrate from 7/8 -> 10). And I think the ”menu button” is the building block that a menu bar consists of.

[heruan]

If these mockups will become a new <vaadin-menu-button> component, that would be ideal so from there it could evolve even more where <vaadin-button> wouldn't.

[heruan]

@jouni Why not having a <vaadin-menu-dropdown> instead, to be used as a dropdown component not only for buttons but also for other elements (e.g. avatars)?

[jouni]

Yeah, I agree, we should have a general purpose dropdown component that is then used to build the more opinionated components. The newish <incubator-popup> component is something like that: https://vaadin.com/components/incubator-popup

[heruan]

The incubator-popup component seems to fit the purpose, but I'm not sure how a commercial product could be used to provide a core feature such as a dropdown menu: I suppose a commercial component prevents its reusability in other elements, e.g. like vaadin-combo-box uses vaadin-text-field.

I didn't inspect each codebase yet, but I'd expect vaadin-select, vaadin-como-box, vaadin-context-menu and incubator-popup to share the same overlay/dropdown component already; then it should be quite straighforward to use the same on buttons, isn't it?

[jouni]

Yes, I would expect that as well, the popup/dropdown to be a shared, reusable part in all of those components.

But in reality, all of them implement the same feature separately. All of them use <vaadin-overlay>, but all the positioning and sizing logic are not shared.

The incubator-popup was custom built for a specific purpose in a customer project by a service developer, which partly explains why there’s not yet another dropdown component.

We’ll see when we have the time to implement an official general-purpose dropdown component (non-commercial) and after that start looking at migrating all the existing components to use that.

[heruan]

Any update/milestone for this?

[jouni]

We are working on the design this week together with @tomivirkki. The current idea is that we focus on the specific “menu bar” use case first (e.g. File, Edit, View, ...). We expect that we will end up building a <vaadin-menu-button>, at least internally, which we can package as a separate component after that.

The API to set the dropdown menu items will likely be the same as in the hierarchical context menu, i.e. items property: https://cdn.vaadin.com/vaadin-context-menu/4.3.1/demo/#context-menu-items-demos

[heruan]

As discussed in https://github.com/vaadin/vaadin-menu-bar-flow/issues/34 the vaadin-menu-bar isn't the right component to achieve this. So, this is what I've tried so far:

1. find a way to style a composite/group button
2. find a way to stick the context-menu to one of the buttons

I've failed at both: I've tried to set a custom theme to let two buttons appear as one, but I couldn't spot the style to override (is it a margin?); also tried positioning the context menu as described in vaadin/vaadin-context-menu#153 (comment) but it didn't work for me (at least in Flow with executeJs).