feat: Card component

[jouni]

Documentation is lacking CSS custom props/styling. Not sure if anything else. Oh, tests, of course 😄

Light	Dark

[jouni]

Should I spend time reducing the duplication?

[knoobie]

This looks kinda basic 🙂 no support for header, content and footer like dialog? Unify API and usage for developers before they have to do it again and again

[jouni]

Thanks for the feedback! Yeah, we are very much aware of this. We are just not yet sure how we want to implement all of that and what kind of API would be suitable, and want to move quite slowly in the beginning before locking in on anything more specific.

We just spent some hours talking with @rolfsmeds about this, and how card relates to the proposed "item" component, and the other "header-content-footer" component we’re thinking about, how all those fit together ("Are they the same component or smaller pieces you need to compose together to get what you need? If they’re not the same component, how do we share the styles and layouts between them? How do we name all of them? Could they just be utility classes? How does all of that affect discoverability? What is even knowledge?").

[jouni]

And as you mentioned Dialog, we also touched on that, and will likely want to refactor it to use the "header-content-footer" layout we’re pondering (eventually, whenever that might happen).

[knoobie]

Thanks for publishing your thoughts 🙂 I was sadly kinda expecting it.. especially combined with the recent discussion you linked.

My concern comes from the way of using / adapting to a new component: what is the benefit for me as developer? If it's just a "wrapper" with no real functionally (header footer and so on) it "feels" unfinished - which lefts me with two options: don't use it.. or use it, extend it and customize it. Often I'm seeing myself doing the second option because - if available - I want to use the official component as base. Which in turn creates problems when "unfinished" components gets later enriched because this can clash with my already enhanced version of it. That's why I mentioned Dialog where exactly that happened when I migrated to your provided header and footer slots. IMHO those "basic" constructs should have been available at the beginning... Therefore I would request them here as well.. even tho it could push this component one minor release in the future when some designs are needed.. it would highly benefit customer before they have to work three times implementing / using it.

1. Ditch their implementation for yours
2. Customize your implementation because it's not enough
3. After your implementation is enhanced.. get rid of customizing

While I agree that it your be beneficial to have a shared item base for dialog, card and what not for.. it feels kinda overenginered IMHO.. yes they could share styles.. but I personally would be against it. This could easily create problems where you wanna style "vaadin-item" however since vaadin-dialog is also using it.. those customizing might leak or developers are not aware of the consequences.. especially when you squeeze in css variables.

[web-padawan]

I'd suggest to keep this example minimal and not use any CSS classes here since users who are unfamiliar with Lumo utility classes might think they are somehow part of the component. Not a blocker though.

[jouni]

Yeah, sounds fair. I’ll try to think of an example that doesn't need utility classes on the card itself.

[web-padawan]

Changed to minimal example for now, we can update JSDoc in a separate PR later.

[web-padawan]

Rebased the PR, updated version in package.json and feature flag to cardComponent.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[vaadin-bot]

This ticket/PR has been released with Vaadin 24.6.0.alpha4 and is also targeting the upcoming stable 24.6.0 version.