Skip to content

POC Card Web Component #4604

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
22 of 24 tasks
alizedebray opened this issue Feb 4, 2025 · 5 comments · May be fixed by #5491
Open
22 of 24 tasks

POC Card Web Component #4604

alizedebray opened this issue Feb 4, 2025 · 5 comments · May be fixed by #5491
Assignees
Labels
📦 components Related to the @swisspost/design-system-components package needs: 🏓 dev roundtable To be discussed at the roundtable of esteemed developers ⏲ timeboxed: 1 day Spend one day on this issue. If you're not able to complete it, it's not worth pursuing further.

Comments

@alizedebray
Copy link
Contributor

alizedebray commented Feb 4, 2025

          Question to the team: should we hide buttons and links that aren't in interactive cards to prevent misaligned UI?

Originally posted by @alizedebray in #4577 (comment)

Card WebComponent POC specs

We have a lot of different but similar cord components (CSS) which could be simplified, by just implementing one web-component, which is then also able to handle (for example) adding a link delegator on the card if necessary.

Proposal

Add a card web-component, which combines our current CSS components card, card-button, card-product and card-teaser into a single component with props to manage how it should look and/or work.

Variant Card

  • Can be used with or without image.
  • The image can be shown on top or on the bottom of the card.
  • Must contain a card-body with any content.
  • The card-body can contain a card-title and card-subtitle element.
  • Can contain a card-header above the card-body with content rendered as flexbox-items (horizontally).
  • Can contain a card-footer below the card-body with content rendered as flexbox-items (horizontally).
  • If the card-header, card-body or card-footer contains a link or a button, the whole card should act as an interactive element (add interactive card styles) and delegate registered clicks to the first interactive element within.
  • Make sure the helper classes .card-title, .card-subtitle, .card-text, .card-links, etc. can be used on slotted elements.
  • Must work with palettes.

Variant card-product

  • Can not be used with an image (above or below).
  • Can be used as a link or as none-interactive element.
  • Must contain at least one card-body with a heading (h1-h6) and a .lead text.
  • Can contain multiple card-body elements (consider offering a sub-component (e.g. post-card-section) to offer a proper way to add more card-bodies).
  • All card-body elements must work with palette classes.
  • Can contain any content.
  • If used as a link, card-body must contain a call-to-action (link).
  • If used as a link, the whole card should act as an interactive element (add interactive card styles) and delegate registered clicks to the first interactive element within.

Variant card-teaser

  • Must contain an image (above).
  • Must be used as a link.
  • Must contain a card-body.
  • Can contain any content.
  • Must contain a call-to-action (link) in the card-body.
  • The whole card should act as an interactive element (add interactive card styles) and delegate registered clicks to the first interactive element within.
  • Must work with palettes.
@alizedebray alizedebray added the needs: 🏓 dev roundtable To be discussed at the roundtable of esteemed developers label Feb 4, 2025
@alizedebray
Copy link
Contributor Author

alizedebray commented Feb 13, 2025

Possible resolution:

  • Create a post-card component to check whether the card contains one or more interactive element and adapt the styles accordingly
  • Write documentations that help users decide on which card styles to use but do not hide the buttons if the wrong styles are used

@gfellerph
Copy link
Member

Resolution: Make a POC as a base of discussion for <post-card> web component that abstracts decisions around having the <post-linkarea> or not and provides slots for all possible content.

@gfellerph gfellerph removed the needs: 🏓 dev roundtable To be discussed at the roundtable of esteemed developers label Feb 20, 2025
@gfellerph
Copy link
Member

gfellerph commented Feb 20, 2025

@oliverschuerch refine the issue to reflect the new task of creating a POC

@gfellerph gfellerph added ⏲ timeboxed: 1 day Spend one day on this issue. If you're not able to complete it, it's not worth pursuing further. 📦 components Related to the @swisspost/design-system-components package labels Feb 20, 2025
@gfellerph gfellerph added this to the Design v2 milestone Feb 20, 2025
@oliverschuerch oliverschuerch removed their assignment Feb 28, 2025
@gfellerph gfellerph changed the title Should we hide buttons and links in non-interactive cards POC Card Web Component Mar 12, 2025
@gfellerph gfellerph moved this from 👀 Triage to 💻 Ready for development in Design System Production Board Mar 12, 2025
@gfellerph gfellerph moved this from 💻 Ready for development to 🆗 Ready in Design System Production Board Mar 13, 2025
@leagrdv leagrdv self-assigned this May 12, 2025
@leagrdv leagrdv moved this from 🆗 Ready to 💻 In Progress in Design System Production Board May 13, 2025
@leagrdv leagrdv linked a pull request May 14, 2025 that will close this issue
@leagrdv
Copy link
Contributor

leagrdv commented May 14, 2025

POC is available here (scroll to the bottom of the cards docs to see it)

The snapshots for different scenarios are here

Pros and cons from what I've seen so far:

Pros:

  • Less code for developers - Structure, styles and logic are encapsulated.
  • Automatic link detection - No manual use of the <post-linkarea>, reducing errors.
  • Structure validation - Though I didn't have time to implement it, having a web component helps with checking the correct usage of each variant.
  • Single entry point - One component (two, counting the <post-card-section>) handles all card variations.

Cons:

  • Big breaking change - Teams must migrate from old class-based usage.
  • More logic inside - Adds JS complexity to what was mostly CSS
  • Performances - In the <post-card>, I've added logic to detect whether there is a link or button within the component to add the <post-linkarea> or not, which itself also checks for the present of a link. This doubles the parsing which isn't great for performances. Though we could find an alternative (e.g. add a prop to the <post-linkarea> to give him directly the interactiveElement)
  • Component complexity - One component handling all variants (card, card-product and card-teaser) can confuse developers; and with the addition of the <post-card-section>, it adds even more complexity to it.

@leagrdv leagrdv added the needs: 🏓 dev roundtable To be discussed at the roundtable of esteemed developers label May 14, 2025
@leagrdv leagrdv moved this from 💻 In Progress to 🧐 In Review in Design System Production Board May 14, 2025
@alizedebray
Copy link
Contributor Author

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📦 components Related to the @swisspost/design-system-components package needs: 🏓 dev roundtable To be discussed at the roundtable of esteemed developers ⏲ timeboxed: 1 day Spend one day on this issue. If you're not able to complete it, it's not worth pursuing further.
Projects
Status: 🧐 In Review
Development

Successfully merging a pull request may close this issue.

4 participants