Considerations for Creating a Card Component

const Card = props ={
  return(
    <div className="card"<h2{props.title}</h2<p{props.content}</p</div)
}

Celý článek

Here's a Card component in React:

const Card = props => {
  return(
    <div className="card">
      <h2>{props.title}</h2>
      <p>{props.content}</p>
    </div>
  )
}

It might be pretty useful! If you end up using this thing hundreds of times, now you have the ability to refactor a little bit of HTML across your app very easily. You already have that power in CSS because of the class name there, but now you have HTML control too. Feel it.

But wait. Maybe this is limiting... an <h2>? What if that really should have been an <h4> in some usages? What's the approach there? Maybe an API of sorts?

const Card = props => {
  return(
    <div className="card">
      {props.type === "big" && <h2>{props.title}</h2>}
      {props.type !== "big" && <h4>{props.title}</h4>}
      <p>{props.content}</p>
    </div>
  )
}

Or maybe we force a level to be passed in?

const Card = props => {
  const HeaderTag = `h${props.level}`;
  return(
    <div className="card">
      <HeaderTag>{props.title}</HeaderTag>
      <p>{props.content}</p>
    </div>
  )
}

Or maybe that header is its own component?

And a forced paragraph tag wrapper around that content? That's a little limiting, isn't it? Maybe that should be a <div> so that it could take arbitrary HTML inside it, like multiple paragraphs.

const Card = props => {
  return(
    <div className="card">
      <WhateverHeader>{props.title}</WhateverHeader>
      <div>{props.content}</div>
    </div>
  )
}

Actually, why even ask for content with props? It's probably easier to deal with a child component, especially if what is coming over is HTML.

const Card = props => {
  return(
    <div className="card">
      <WhateverHeader>{props.title}</WhateverHeader>
      {children}
    </div>
  )
}

There are more assumptions we could challenge too. Like card only for a class name... shouldn't that be more flexible?

const Card = props => {
  const classes = `card ${props.className}`;
  return(
    <div className={classes}>
      <WhateverHeader>{props.title}</WhateverHeader>
      {children}
    </div>
  )
}

I'm still forcing card there. We could drop that so that it isn't assumed, or build another aspect of the Card API providing a way to opt-out of it.

Even the <div> wrapper is presumptuous. Perhaps that tag name could be passed in so that you could make it into a <section> or <article> or whatever you want.

Maybe it's better to assume nothing actually, making our card like this:

const Card = () => {
  return(
    <>
      {children}
    </>
  )
}

That way anything you want to change, you have the freedom to change. At least then it's flexibility while being relaxed about it, rather than this kind of "flexibility":

<Card
  parentTag="article"
  headerLevel="3"
  headerTitle="My Card"
  contentWrapper="div"
  cardVariation="extra-large"
  contentContent=""
  this=""
  little=""
  piggy=""
  went=""
  to=""
  market=""
/>

That kind of extreme-API-zying just happens sometimes when you're grasping for control and flexibility at the same time.

A component model with no guidance can lead to over-componentization also, like perhaps:

const Card = props => {
  return(
    <CardWrapperTheme>
      <CardWrapper>
        <CardTitle />
        <CardContent />
        <CardFooter />
      </CardWrapper>
    </CardWrapperTheme>
  )
}

There might be perfectly good reasons to do that, or it might be the result of componentizing because it's "free" and just feels like that's how things are done in an architecture that supports it.

There is a balance. If a component is too strict, it runs the risk of that people won't use them because they don't give them what they need. And if they're too loose, people might not use them because they don't provide any value, and, even if they did use them, they don't offer any cohesiveness.

I don't have any answers here, I just find it fascinating.

The post Considerations for Creating a Card Component appeared first on CSS-Tricks.