Consideraciones para crear un componente de tarjeta

Aquí hay un componente de tarjeta en React:

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

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

Pero espera. Quizás esto sea limitante… ¿un h2? ¿Qué pasaría si eso realmente debería haber sido h4en 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 el paso de 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? Tal vez debería ser divasí para que pueda contener HTML arbitrario, como varios párrafos.

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

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

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

Hay más suposiciones que también podríamos cuestionar. Tarjeta Me gusta 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 cardallí. Podríamos eliminarlo para que no se dé por sentado, o crear otro aspecto de la API de tarjeta que proporcione una forma de cancelar su participación.

Incluso el divenvoltorio es presuntuoso. Quizás el nombre de esa etiqueta podría pasarse para que puedas convertirlo en sectiono articlelo que quieras.

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

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

De esa manera, cualquier cosa que quieras cambiar, tienes la libertad de cambiarla. Al menos entonces es flexibilidad y estar 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 zying extremo de API ocurre a veces cuando buscas control y flexibilidad al mismo tiempo.

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

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

Podría haber razones perfectamente buenas para hacerlo, o podría ser el resultado de la creación de componentes porque es “gratis” y simplemente 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 la gente no lo utilice porque no le da lo que necesita. Y si son demasiado flexibles, es posible que la gente no los use porque no aportan ningún valor y, incluso si los usaran, no ofrecen ninguna cohesión.

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