Item component

[rolfsmeds]

A component for creating the types of multi-text items typical in lists etc.

• Primary text (also supports slotting elements)
• Secondary text (configurable to be above or below primary text; also supports slotting elements)
• Prefix slot (e.g. for avatar or icon)
• Suffix slot (e.g. for a button or icon)

Example of Item with secondary text below, avatar prefix and button/icon in suffix:

DOM / semantic structure:

• Item root (generic role)
  • slot="prefix"
  • span : primary text
    • slot="primary-content"
  • span : secondary text
    • slot="secondary-content"
  • slot="suffix"

(Note that, although this component will typically be used in lists, it does not have list semantics on its own by default, as many other use cases are equally valid and useful. When used as list item, either apply role="listitem" manually or wrap in one.)

Open questions

Name: vaadin-item is already taken.

[knoobie]

How about vaadin-list-item like the corresponding "LI" stands for list item? :)

[web-padawan]

See also #459 where prefix / suffix slots for item were originally discussed.

[rolfsmeds]

How about vaadin-list-item like the corresponding "LI" stands for list item? :)

Might make users think it should only be used as a list item.

vaadin-item-info?
vaadin-entity?

[knoobie]

That was exactly my intention 🙂 Normally this kind of construct appears multiple times.. immediately triggering our accessibility testers "why didn't you add a list around it?" That's where my comment originated from.

vaadin-item-info sounds reasonable, even tho I've got the feeling people would be confused with the already available vaadin-item and their relationship

vaadin-entity would be IMHO a nightmare for Java users because of the meaning of entity in that eco system

[web-padawan]

IMO we should eventually update vaadin-list-box to use something like vaadin-list-item. Originally, vaadin-item was supposed to be used by vaadin-select and vaadin-context-menu but they have individual item components now.

Regarding this component, overall I'm not convinced such a simple layout should be in the core component set.
Even using Flow it should be quite easy to build with FlexComponent or just Div with a few utility classes.

[rolfsmeds]

While it's certainly technically trivial to do, it's not trivial for your average Java developer (our core userbase) to figure out the Div structure and, most of all, get the styling right so that it actually looks nice. Also, the idea is to provide a few different visual variants out of the box.

As an example, even I spent a disproportionate amount of time tweaking paddings, font sizes, colors and line heights to get the avatar+username part to look nice in the User Menu Popover example, and I'm a UI designer with ~20 years of css experience.

[knoobie]

While it's certainly technically trivial to do, it's not trivial for your average Java developer (our core userbase) to figure out the Div structure and, most of all, get the styling right so that it actually looks nice.

Interesting thought that opens the question in my mind: should there be more java only components? Because they are technically just some divs (people familiar with JS / webcomponents / react) could easily do them yourself

[rolfsmeds]

I have pondered the same question myself.

It does go against the principle we've been trying to uphold of not "fragmenting" the design system by having some components only available for Flow or React (to a greater extent than what we have today), as the parity we (mostly) have today is definitely beneficial with regards to documentation, start.vaadin.com templates, the Copilot palette, for developers working on mixed Flow/Hilla apps, etc.

On the other hand, if there are UI patterns that are truly trivial for a front-end developer, but not so for Java developers, there could certainly be cases where that would make sense.

That being said, I'm not convinced this is such a case. Having an out-of-the-box solution available for a super-common pattern does provide value for frontend developers too, since they don't have to spend time creating their own in every project.

If you look at other popular component libraries, they do have plenty of simple, non-interactive building blocks like this (and event significantly simpler ones), e.g.

• https://www.radix-ui.com/themes/docs/components/inset
• https://primereact.org/chip/
• https://ionicframework.com/docs/api/item
• https://material.angular.io/components/divider/overview
• https://react-bootstrap.github.io/docs/components/badge
• https://mui.com/material-ui/react-chip/

[jouni]

Thought of the day: should this be combined with the Card component? What would go wrong if we bundled these use cases together? At the moment I’m thinking it’s the same use case: packaging predefined set of utility classes / CSS behind a more convenient API.

Also: do we need slots and shadow DOM? Wouldn't CSS grid suffice?