POC Card Web Component

[alizedebray]

          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]

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]

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]

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

[leagrdv]

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.

[alizedebray]