Cards

[zecarlostorre]

Card is the second most used component in the admin, but it’s also the one with the most overrides.
This is a problem because these overrides naturally contribute to less coverage, but they also underline two big issues with the card component, it being too complex and too opinionated.

Why?
Visually, a card is just a container of content with a predefined color, corner radius and shadow. In theory, it should be simple, but in practice we have 3 components that are cards (Card, MediaCard and CalloutCard).
Not to speak of other card-like components that could benefit from sharing simple foundations with the card (Banner, Modal, Popover, and more).
Even if we just isolate the Card component, we end up with 14 props that feel like an overengineered attempt to give a limited level of composability.

I believe we need to:
Build a simple card foundation based on a Box component.
Make card layouts more composable and reduce the amount of props, by building Card templates on top of the new simpler foundations (Box*+Box style**+Box density***)

We could follow this up by identifying other components that can be rebuilt using Box (Probably start with Banner & Modal, based on usage).

*Box is a foundational component that can be used to draw something as a simple rectangle with rounded corners, or something as complex as a resource list.
**Box style includes a background color, border, rounded corners and shadow.
***Box density refers to the padding

[alex-page]

Users have mentioned they want clickable cards.

Cards could be more reusable if they supported different background colors (banners, toast). Cards have no flexibility for inner spacing unless you detach from the system.

[heyjoethomas]

This is the big one. +1

[heyjoethomas]

Creating a <box> component would radically change everything. Which isn't to say its a bad or a good idea, just very different. In a sense almost everything is a box. So I think the details of how we implement and structure the api here would be super critical.

[alex-page]

@gil-- mentioned today on twitter that there isn't a way to build the "stats bar" pattern with our card today.

[aveline]

We have started working on a new more composable Card component so I wanted to pick up this discussion again.

My initial thought after building a basic card with our prototype Box component is that without some design opinions, Card doesn't add much value over Box. Similar to how our new Text component is a grouping of design opinions that make it quicker to use than an html h2, I see Card as offering the same making it quicker to use than Box.

I do think Card shouldn't concern itself with its children and that should be completely flexible. I see it looking something like this.

// current Card       
<Card title="Online store dashboard" sectioned>
  <p>View a summary of your online store’s performance.</p>
</Card>

// new Card
<AlphaCard>
  <AlphaStack>
    <Text as="h2" variant="headingMd">
      Online store dashboard
    </Text>
    <p>View a summary of your online store’s performance.</p>
  </AlphaStack>
</AlphaCard>

Renders as

What are the design opinions or sensible defaults that should be included with Card?

Our existing Card component is pretty opinionated with regards to border-radius, background-color and padding. Are those design opinions we want to carry forward with the new version of Card?

[heyjoethomas]

I agree with the overall opinion here. Card should have defaults for bg color, radius, shadow and padding. I think padding might need to be overridable via prop but we can at least set the default that should cover 90%+ of use cases. This would make sections of the card more composable and allow different padding in different sections or an easy way to set things full-width.

I don't think things like Banner and Modal should be using the Card component since they have radically different purpose and presentations. Those could be based on something like Box but I don't think it should be Card.

[tjonx]

IMO, this is tied closely to the future Layout component.

Should Card even have padding if we could, hypothetically, give Layout the option of having margins?

[sarahill]

Should Card even have padding if we could, hypothetically, give Layout the option of having margins?

That's a fair question. My thought was, as a container, the Card would have adjustable inner padding and then the primitive layout components would control any layout and space within that.

I can see a case where a team might what something to go edge to edge against a card, like a divider for example, and in that case I imagine you wouldn't leverage the Card padding or it would be set to none and you'd use the primitives to achieve the padding and margins needed.

If we decided not to include padding on the Card I think we would just lean more into the guidance for how you would compose which also feels like it supports the direction we want to head in.

[heyjoethomas]

My thought was, as a container, the Card would have adjustable inner padding and then the primitive layout components would control any layout and space within that.

Totally agree Sara. I think the Card as a container is different than a layout component that handles the spacial relationship between content or multiple Card components.

In my mind a sensible default makes sense here. If we know the majority of Card components have an inner padding of 20px, then we could make that the default but allow it to be changed via props so we maintain flexibility and composability.

[aveline]

That's a fair question. My thought was, as a container, the Card would have adjustable inner padding and then the primitive layout components would control any layout and space within that.

This is how I was thinking about it and I will create some examples with the alpha Card component.

The benefit of including padding on Card is for simple use cases like the screenshot example at the start of this thread

<AlphaCard>
  <AlphaStack>
    <Text as="h2" variant="headingMd">
      Online store dashboard
    </Text>
    <p>View a summary of your online store’s performance.</p>
  </AlphaStack>
</AlphaCard>

This works with padding on the card. If we didn't include any, then we have to include an additional primitive layout component just to add the padding.

<AlphaCard>
  <Box padding="2">
    <AlphaStack>
      <Text as="h2" variant="headingMd">
        Online store dashboard
      </Text>
      <p>View a summary of your online store’s performance.</p>
    </AlphaStack>
  </Box>
</AlphaCard>

I prefer the simplicity of not having to do that for basic use cases.

[IrinaLipovaya]

Hey! In the Money team, we have several use cases of "editable area in the card" (more details in the thread). How would you advise to approach this use case? Would it be better to have it as a part of Card component functionality or create a separate component in /components in the web codebase?

[aveline]

Given that we are in the process of creating a new Card component, not sure how much value would be gained from extending the current Card to support this functionality. Perhaps a separate component is the simpler way to go at this point.

But sharing this use case is super valuable as we think about what the new Card component should support so thank you for sharing that!