Badge component

[Artur-]

Describe your motivation

Lumo has styles for a badge but they are unintuitive to use. It would be much more intuitive if there was a <vaadin-badge> component.

Describe the solution you'd like

The feature set needed for a <vaadin-badge> component is quite small, with the most typical features being:

1. You can set the text
2. You can set the style. The predefined styles available in Lumo work fine: error, success, small, contrast, primary, pill
3. You can add an icon to the badge, before or after the text

You might also want to:

1. Add a tooltip to the badge

Describe alternatives you've considered

No response

Additional context

No response

[web-padawan]

As we already have theme presets for badge-like elements in Lumo, what would be our plan regarding those?
Do we keep existing styles and reuse in vaadin-badge while also keeping an option to use them separately?

[Artur-]

I would deprecate the badge part of Lumo with the aim to remove them and guide people to use <vaadin-badge> instead

[web-padawan]

We also need to figure out a Flow API and we could discuss it in the same issue (could be also GitHub discussion).
Existing API for badges is a bit inconvenient, but it's still only 2 lines of code unless you also want to add an icon:

Span pending = new Span("Pending");
pending.getElement().getThemeList().add("badge");

Suggestion from the daily: wrap that code inside a factory in Flow Components, something like Badge.create()

[web-padawan]

Some more considerations for vaadin-badge component to discuss and agree upon, before implementing it:

1. Do we also use the new "badge" a base for vaadin-multi-select-combo-box-chip as they seem quite similar?
2. What the Material theme should look like? Would it make sense to use the new Material v3 chips as a base?

@jouni WDYT about this? Personally, I would like us to cover both if we agree to introduce a badge component.

[Artur-]

The most relevant Flow API could be

new Badge("Hello");
new Badge("Hello", BadgeVariant.PILL);
badge.setText("Goodbye");
badge.setVariants(BadgeVariant.PRIMARY);

Not sure why we would need a factory method, no other components have that

[web-padawan]

Fair enough. We would need to have BadgeVariant enum on the Flow side and implement HasThemeVariant as well.
In case of the vaadin-badge component, we probably don't need badge theme, so that HTML would look like this:

<span theme="badge primary">I'm a badge.</span>
<vaadin-badge theme="primary">I'm a better badge!</vaadin-badge>

[tomivirkki]

Not sure why we would need a factory method, no other components have that

Badge could be a simple Flow-only component as well, right?

public class Badge extends Span {

  public Badge(String text, BadgeVariant variant) {
    setText(text);
    getElement().getThemeList().add("badge");
    ...
  }

}

[Artur-]

Yes it can be Java only if other web developers never need a badge component. It currently feels more like a jquery component that somehow ended up in a web component set

[TatuLund]

My first thought was to do it like @tomivirkki proposes. But then I ended up wrapping lumo-badge styles in the web component like this https://github.com/TatuLund/badge/blob/v23/src/main/resources/META-INF/resources/frontend/badge.ts

This allowed me to add tooltip support nicely too.

Java API is here: https://github.com/TatuLund/badge/blob/v23/src/main/java/org/vaadin/addons/badge/Badge.java

[TatuLund]

It currently feels more like a jquery component that somehow ended up in a web component set

Somewhat yes, in Flow app it is abstracted away, if you use it only thru Java API. The difference becomes more visible in Hilla, like here:

https://github.com/TatuLund/hilla-demo/blob/master/frontend/views/list/renderers.ts#L23

So how much improvement it is?

          <span theme="badge" class="ml-auto text-s">
            ${lang.getText(uiStore.lang,contact.status.name)}
          </span>

vs.

          <vaadin-badge class="ml-auto text-s">
            ${lang.getText(uiStore.lang,contact.status.name)}
          </vaadin-badge>

[web-padawan]

One thing about vaadin-badge in the above example is that regardless of span or vaadin-badge, users would still have to use both class and theme combined for e.g. primary variant, which is probably not so nice in terms of DX.

Note, Lumo utility classes generally shouldn't be used for Vaadin components, but they are OK for span or div etc.

[Artur-]

Note, Lumo utility classes generally shouldn't be used for Vaadin components, but they are OK for span or div etc.

Do you mean inside Vaadin components? Because using them on the component instances sound perfectly fine, just like it is fine to use CSS

[Artur-]

One thing about vaadin-badge in the above example is that regardless of span or vaadin-badge, users would still have to use both class and theme combined for e.g. primary variant, which is probably not so nice in terms of DX.

How do you mean? <vaadin-badge theme="primary">I'm a better badge!</vaadin-badge> requires no class. If you want to do other styling, you would use class of course, or style. The theme attribute in this case is similar to a component property. It could also be type but I'm not sure what that would improve