Cuándo dos componentes parecidos deberían seguir separados

Dos tarjetas pueden parecer de la misma familia y necesitar contratos distintos.

En yesid.dev-design, los requisitos documentados de Transit y yesid.dev hacen concreta esa diferencia. Transit espera una tarjeta plana, sin sombra ni borde resaltado. yesid.dev conserva un bisel y una sombra al pasar el cursor. Comparten una identidad visual. Sus requisitos siguen siendo diferentes.

Sería fácil poner los dos comportamientos en un paquete compartido si este pudiera preguntar qué producto lo está usando. Las reglas del proyecto excluyen precisamente esa dependencia. Cuando el código común conoce cada producto por su nombre, cada excepción nueva añade otro motivo para modificar la base.

El límite que elegí es más pequeño. El paquete se encarga del control o la superficie común. Un estilo o una adaptación del producto se encarga de la diferencia. Cada producto conserva las verificaciones que explican por qué existe su excepción.

Esto acepta cierta duplicación. También le da una razón y un lugar definido.

La pregunta es si las dos piezas comparten la misma responsabilidad. Su apariencia actual es una pista, pero no resuelve qué hacen, quién controla su estado ni qué cambios deberían recibir juntas.

Una sección plegable es otro ejemplo. En ambos productos puede tener un título, una flecha y contenido oculto. Aun así, puede cambiar la forma de recordar su estado, la composición del encabezado o el comportamiento del contenido cerrado. Compartir los controles básicos resulta útil. Compartir toda la sección también trasladaría decisiones que todavía le corresponden al producto.

El repositorio aplica una regla de tres a los patrones compuestos: tres consumidores independientes deben necesitar el mismo contrato antes de convertirlo en una pieza compartida. Es una restricción de este proyecto, no una fórmula para todos los equipos. Obliga a detenerse antes de tratar un parecido como una abstracción estable.

También hay una consecuencia para las actualizaciones. Una vez que un componente es compartido, un cambio afecta a varios productos. Cada uno adopta una versión exacta y revisa su comportamiento. Un ejemplo que funciona en la galería no responde todas las preguntas sobre una página real.

Esta forma de pensar vuelve más concreta la reutilización. ¿Qué se repite? ¿Qué cambia? ¿Cuáles diferencias son intencionales? ¿Quién decide cuándo deben cambiar?

La respuesta puede ser un componente compartido. También puede ser una pieza básica común con una adaptación local, o dos implementaciones separadas cuyas responsabilidades todavía están evolucionando. Lo útil es poder explicar y verificar el límite elegido.

Conocer el proyecto