Consideraciones para la creación de un componente de tarjeta | Programar Plus

Aquí hay un componente de tarjeta en React:

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

¡Puede ser muy útil! Si terminas usando esto cientos de veces, ahora tienes la capacidad de refactorizar un poco de HTML en tu aplicación con mucha facilidad. Ya tiene ese poder en CSS debido al nombre de la clase allí, pero ahora también tiene control HTML. Sentirlo.

Pero espera. Quizás esto esté limitando … un <h2>? ¿Y si eso realmente debería haber sido un <h4> en algunos usos? ¿Cuál es el enfoque allí? ¿Quizás una especie de API?

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>
  )
}

¿O tal vez forzamos a pasar un nivel?

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

¿O tal vez ese encabezado es su propio componente?

¿Y un envoltorio de etiqueta de párrafo forzado alrededor de ese contenido? Eso es un poco limitante, ¿no? Quizás eso debería ser un <div> para que pueda contener HTML arbitrario en su interior, como varios párrafos.

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

En realidad, ¿por qué incluso pedir contenido con accesorios? Probablemente sea más fácil lidiar con un componente hijo, especialmente si lo que viene es HTML.

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

También hay más suposiciones que podríamos cuestionar. Como una tarjeta solo para el nombre de una clase … ¿no debería ser más flexible?

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

Todavía estoy forzando card allí. Podríamos eliminar eso para que no se asuma, o crear otro aspecto de la API de la tarjeta que proporcione una forma de excluirse.

Incluso el <div> envoltorio es presuntuoso. Quizás ese nombre de etiqueta podría pasarse para que pueda convertirlo en un <section> o <article> o lo que quieras.

Tal vez sea mejor no asumir nada en realidad, haciendo que nuestra tarjeta sea así:

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

De esa manera, cualquier cosa que desee cambiar, tendrá la libertad de cambiar. Al menos entonces es flexibilidad mientras se está relajado al respecto, en lugar de este tipo de “flexibilidad”:

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

Ese tipo de uso extremo de API solo ocurre a veces cuando busca el control y la flexibilidad al mismo tiempo.

Un modelo de componentes sin orientación también puede llevar a una sobrecomponente, como quizás:

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

Puede haber buenas razones para hacerlo, o puede ser el resultado de la creación de componentes porque es “gratis” y parece que así es como se hacen las cosas en una arquitectura que lo admite.

Hay un equilibrio. Si un componente es demasiado estricto, se corre el riesgo de que las personas no lo utilicen porque no les dan lo que necesitan. Y si son demasiado sueltos, es posible que la gente no los use porque no brindan ningún valor y, incluso si los usaran, no ofrecen cohesión.

No tengo ninguna respuesta aquí, simplemente lo encuentro fascinante.