search

vaadin / web-components

A set of high-quality standards based web components for enterprise web applications. Part of Vaadin 20+
https://vaadin.com/docs/latest/components
457 stars 83 forks source link

Item component #7958

Open rolfsmeds opened 1 week ago

rolfsmeds commented 1 week ago

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

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

DOM / semantic structure:

(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 commented 1 week ago

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

web-padawan commented 1 week ago

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

rolfsmeds commented 6 days ago

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 commented 6 days ago

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 commented 6 days ago

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 commented 2 days ago

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 commented 2 days ago

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 commented 2 days ago

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.