El paradigma del diseño basado en componentes ha llegado a Drupal de la mano de SDC y, con ello, han llegado todas las dudas aparejadas a este modo de trabajar.
Aparentemente, un componente es una idea simple. ¿Lo es de verdad? Basándome en mi experiencia en varios proyectos de gran tamaño, no lo es en absoluto. Si nos fijamos en las preguntas recurrentes de los canales de slack dedicados al tema, así como en las issues de Drupal y las discusiones en torno a cómo afrontar ciertas refactorizaciones, veremos que cierta confusión es generalizada.
La arquitectura de un sistema de diseño basado en componentes está atravesada por decisiones que, mal ejecutadas, pueden provocar problemas futuros. Entre otras muchas cuestiones, nos pueden surgir las siguientes dudas:
- ¿Cuándo crear un componente o reutilizar uno ya existente?
- ¿Cuándo usar props o slots?
- ¿Cómo se relaciona un componente padre con sus descendientes?
- ¿Tiene sentido crear dos componentes con un HTML prácticamente idéntico?
- ¿Cuándo y cómo puedo usar variantes?
- ¿Dumb components o smart components?
- ¿Cómo se relaciona un componente con Drupal?
En esta charla discutiremos cuál es la naturaleza de un componente, en qué se diferencia de otros modos de afrontar el front-end de un sitio, cuáles son los consensos en torno a las buenas y malas prácticas, así como qué areas están abiertas a discusión.