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”: Noticias del cadiz

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.






SUSCRÍBETE A NUESTRO BOLETÍN 

No te pierdas de nuestro contenido ni de ninguna de nuestras guías para que puedas avanzar en los juegos que más te gustan.










Al suscribirte, aceptas nuestra política de privacidad y nuestros términos de servicio.






Tal vez te puede interesar:

  1. La innovación no puede mantener la Web rápida
  2. Rendimiento web ultrarrápido
  3. Tabla de contenidos fijos con estados activos de desplazamiento
  4. “cambiar tamaño: ninguno;” en áreas de texto es una mala experiencia de usuario

Consideraciones para crear un componente de tarjeta

Consideraciones para crear un componente de tarjeta

¡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.

programar

es

https://pseint.es/static/images/programar-consideraciones-para-crear-un-componente-de-tarjeta-1303-0.jpg

2024-06-13

 

Consideraciones para crear un componente de tarjeta
Consideraciones para crear un componente de tarjeta

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

 

 

Update cookies preferences