Tematización basada en componentes con el componente de directorio único de Drupal

La tematización de Drupal ha sido un área que durante mucho tiempo no ha sido tocada por una actualización radical. Seguro que hay toneladas de módulos contribuidos disponibles para hacer que el flujo de trabajo sea un poco más fácil, pero el enfoque listo para usar para crear un tema personalizado se ha mantenido más o menos igual. Durante mucho tiempo se ha hablado de tener algún tipo de mecanismo de tematización basado en componentes dentro del propio núcleo de Drupal. Ingrese a los componentes de directorio único (SDC) , que ha estado en discusión durante bastante tiempo a través de un módulo contribuido manejado por destacados colaboradores de Drupal: Mateu Aguilo Bosch, Mike Herchel, Lauri Eskola y Dave Reid. Pero ahora ha entrado en el núcleo de Drupal (actualmente como una característica experimental) en la versión 10.1.

Este enfoque basado en componentes de tematización de una aplicación Drupal no es nuevo, pero finalmente ha llegado al núcleo. Brinda una frontera completamente nueva para que los desarrolladores front-end organicen su código de una manera que sea más fácil de mantener con una curva de aprendizaje mínima. Dentro de SDC, todos los archivos necesarios para renderizar el componente (Twig, CSS, JS, etc.) se agrupan en un solo directorio. SDC tiene el potencial de revolucionar el desarrollo front-end en Drupal al permitir que los desarrolladores aprovechen las últimas técnicas front-end, consolidando la posición de Drupal como un CMS robusto y con visión de futuro.

El enfoque temático actual de Drupal

La forma más sencilla de trabajar en un tema de Drupal ha sido agregar el marcado a los archivos html.twig dentro de las carpetas de plantillas. Para el estilo y el comportamiento, creamos archivos CSS y JS de acuerdo con la necesidad de una entidad y los colocamos dentro de las carpetas CSS y JS respectivamente. Esto incluye el menú de encabezado de temas, el menú de pie de página, los bloques, las regiones, los tipos de contenido individuales y sus diferentes modos de vista, diferentes vistas, etc. Estos archivos se declaran en el archivo library.yml donde también se pueden mencionar las dependencias (si las hay). De esta forma, pueden cargarse bajo demanda o estar disponibles globalmente. Aparte de esto, cualquier lógica de preprocesamiento va a los archivos .theme, tenemos breakpoints.yml para ayudar con los diseños receptivos y, por supuesto, el archivo .info.yml sin el cual todo el esfuerzo es un desperdicio.

Si bien esto parece ser mucho trabajo por hacer antes de que realmente hagamos un trabajo de interfaz útil, ha habido algunos generadores de código repetitivo como drush theme generate , que tienen la intención de generar la estructura de carpetas de un tema de una manera interactiva y crear un Estructura de carpetas estándar de Drupal.

Aunque la estructura anterior funciona lo suficientemente bien para iniciar un proyecto y no puede representar un problema para un proyecto pequeño, puede convertirse en un cuello de botella para los sitios web empresariales donde se necesita integrar un sistema de diseño más sofisticado.

1. Las cosas comienzan a desordenarse muy rápidamente. Vemos muchos archivos CSS y JS llenos hasta el borde en sus carpetas.
2. Los desarrolladores luchan por encontrar el código que pueden reutilizar o ampliar.
3. Surgen problemas como la duplicación de código, la distribución del código en los archivos, el infierno de la especificidad y los conflictos de CSS.
4. Esto a menudo conduce a más esfuerzos dedicados al desarrollo posterior donde se espera que el desarrollo inicial hubiera ayudado más adelante.

Nuestro enfoque de la tematización en Specbee

En Specbee, hemos estandarizado la forma en que creamos nuestros temas utilizando una herramienta de NPM llamada Drupal Theme Init, desarrollada por nosotros desde cero y de código abierto. Al ser un generador Yeoman, se puede instalar fácilmente con NPM/Yarn, que luego ayuda de forma interactiva en la generación de un tema personalizado. La idea de Drupal Theme init es tener un enfoque coherente sobre cómo se estructuran los archivos de temas siguiendo las prácticas de Drupal y ayudar a los desarrolladores a comenzar a trabajar en el tema sin la molestia de configurar los archivos cada vez que inician un nuevo proyecto. La idea básica de la estructura es compartimentar SASS en componentes utilizando la convención BEM. Cada archivo CSS asociado con una entidad como bloque, vista, tipo de contenido, etc. tiene su propio CSS generado y se adjunta a esa entidad a través de la plantilla twig o el preprocesamiento. Lo mismo ocurre con los archivos JS. El uso extensivo de library.yml nos ayuda a limitar la cantidad de CSS y JS que representamos en la página.

La ventaja de configurar el tema de esta manera es que tenemos un sistema para la tematización basada en componentes sin depender de bibliotecas o complementos externos. Nos ayuda a segregar las bibliotecas CSS/JS en función de los componentes que se cargarán en la página, lo que ayuda con el rendimiento. Sin embargo, todavía existen limitaciones para este enfoque, especialmente cuando el proyecto crece en tamaño. La segregación de componentes en niveles atómicos se convierte en una carga, ya que requiere que mantengamos el archivo library.yml con las dependencias requeridas. Además, no hay una manera fácil de hacer una integración adecuada de un sistema de diseño con la estructura actual, ya que tendremos que definir la ruta de cada componente y su dependencia por nosotros mismos en el sistema de diseño también, para cargar los componentes en él.

¿Qué es la tematización basada en componentes?

Si bien el enfoque de vainilla parece bastante básico, se han realizado grandes cantidades de avances en los últimos tiempos a través de módulos contribuidos para tener mejores enfoques. Uno de los enfoques populares es imaginar la interfaz de usuario como una colección de unidades consistentes y reutilizables llamadas componentes . En la mayoría de los casos, esto sigue el diseño atómico donde cada componente se segrega en bloques de construcción más pequeños. ¡Módulos como patrones de interfaz de usuario, componentes! o bibliotecas de componentes como PatternLab, Fractal y Storybook han traído formas innovadoras que han hecho que el desarrollo de temas sea más ágil y sólido. La tematización basada en componentes tiene cierta ventaja sobre la tematización tradicional:

1. Uno de los cuellos de botella más grandes es la dependencia del backend, donde el trabajo del frontend no puede comenzar sin el trabajo del backend. Esto crea un retraso. Usando un enfoque basado en componentes, el front-end puede funcionar de forma independiente y sin un conocimiento profundo de las cosas de Drupal.
2. Los componentes se pueden crear solo a partir del diseño disponible con los marcadores de posición requeridos. Los valores para estos marcadores de posición se pueden completar más adelante cuando se complete el trabajo de back-end
3. Crea un flujo de trabajo en el que simplemente no cambiamos el marcado en la carpeta de plantillas y lo diseñamos según el requisito. Más bien, tenemos estructuras más pequeñas diseñadas por separado y luego creamos una colección de estas unidades más pequeñas en componentes más grandes que pueden ser utilizados por las plantillas de Drupal.
4. Esto ayuda a mantener el código relacionado con cada componente de forma aislada y crea menos posibilidades de efectos secundarios.
5. Confirma la consistencia de UX en toda la aplicación.
6. Ayuda a reducir los esfuerzos dedicados a configurar la función, ya que los cambios realizados en un lugar se reflejan en las áreas donde se utiliza.

Cómo hacer una tematización basada en componentes en Drupal

Una de las formas destacadas de seguir el desarrollo basado en componentes es usar PatternLab, que se introdujo hace bastante tiempo. Inicialmente vino con una edición de Drupal que ahora está archivada y reemplazada por un paquete basado en nodos. La configuración de PatternLab requiere la instalación de un módulo de componentes que ayudará a obtener el marcado de los archivos Twig fuera de la carpeta de plantillas para Drupal. A esto le sigue la instalación del paquete patternlab a través de npm, que ofrece opciones para generar plantillas basadas en twig o bigote (obviamente, twig para nosotros). Una vez hecho esto, tenemos una guía de estilo lista, un código repetitivo que ayuda en la creación de la guía de estilo y una carpeta de patrones donde creamos los componentes de acuerdo con los requisitos. Estos componentes luego se incluyen en los archivos html.twig presentes dentro de la carpeta de plantillas.

Si bien todos estos pasos están bien para realizar, hay casos en los que esto es un poco difícil de configurar y tiene una pequeña curva de aprendizaje. El mayor inconveniente que viene con Patternlab es que todo el CSS se agrega en un solo archivo que luego se vuelca en todas las páginas (que a veces también es el caso con el JS incluido). Si bien esto no importa inicialmente, ya que la idea básica es la reutilización del componente, una vez que el proyecto crece, esto comienza a afectar el rendimiento de la página.

Cómo hacer una tematización basada en componentes con SDC

Con la versión inicial de SDC entrando en el núcleo como un módulo experimental, ha habido mucho entusiasmo a su alrededor. SDC ha sido promocionado como el mayor cambio en la temática de Drupal desde la introducción de Twig. Nuevamente, SDC no es una solución completa para el equipo de desarrollo de frontend, sino un enfoque basado en componentes para la creación de temas con una estructura básica lista para usar. Esto todavía se puede ampliar con una serie de módulos para un cierto tipo de flujo de trabajo. La idea básica es que todo lo relacionado con un componente permanece dentro de un solo directorio. Esto incluye el archivo Twig del componente, JS, CSS, otros activos y un archivo YAML de esquema único que declara las propiedades del componente.

Algunos beneficios inmediatos de usar SDC:

1. Todo el código relacionado con un componente está en un solo directorio (¡como sugiere el nombre!).
2. Las bibliotecas para el componente se generan automáticamente, lo que reduce el trauma de no declararlo en el archivo library.yml. Aunque es posible que todavía necesitemos agregar las dependencias al archivo component.yml, esto se hace en un solo lugar en lugar de saltar al archivo library.yml.
3. Hay una curva de aprendizaje mucho más pequeña para implementar SDC. Si conoce lo básico de la tematización de Drupal, todo lo que necesita hacer es habilitar este módulo y comenzar a escribir los componentes.
4. El poder de twig (incluir/extender/incrustar) todavía está disponible, lo que ayuda en la reutilización del código.
5. Como los componentes son complementos YML, que Drupal puede descubrir fácilmente y se pueden intercambiar fácilmente por un componente que tenga la misma estructura de API.
6. ¡Los componentes también se pueden renderizar a través de matrices de renderizado!
7. Proporciona un buen mecanismo para integrar bibliotecas externas para facilitar un sistema de diseño.
8. A medida que se organizan los componentes, el resultado es una apariencia uniforme del producto final.
9. El código se vuelve más comprobable ya que tenemos unidades (leer componentes) que se pueden probar de forma independiente
10. Debido a que definimos el esquema dentro de la definición YAML de un componente, los módulos pueden crear formularios automáticamente para completar los datos.

Aunque actualmente se incluye como una característica experimental en el núcleo, configurar SDC es bastante fácil. Asumiendo que hay una instalación de Drupal 10.1.x:

1. Habilite el módulo central SDC experimental.

2. Cree o use un tema personalizado para agregar SDC. Para nuestro propósito, creamos un tema personalizado llamado Helado con Olivero como tema base.

3. Para nuestro propósito, usemos la página básica que viene de la caja. Lo he reutilizado agregando un campo de Título personalizado y haciendo algunos ajustes en la pantalla que luego se ve así:

4. El archivo twig de la plantilla consiste en un código básico:

5. Cree una carpeta llamada componentes dentro de su tema personalizado. Esto es similar a cómo tenemos una carpeta de plantillas para las plantillas de Drupal.

6. Por ahora, la idea básica es diseñar el título y la descripción, que serán de naturaleza reutilizable. Vamos a crear un componente llamado simple-article. Habrá un archivo simple-article.component.yml y simple-article.twig que necesitaremos. Aparte de eso, también agregaremos simple-article.css para diseñar.

7. Vamos a crear el archivo simple-article.twig . Tendremos un marcado básico para eso.

8. Agregue el archivo simple-article.component.yml con el esquema mencionado en https://www.drupal.org/node/3352951. La idea es definir cuáles serán las entradas al archivo twig. Nos quedará algo así:

9. Agreguemos un estilo básico al componente en simple-article.css .

10. Limpia la memoria caché.

11. ¡Abracadabra! El componente ya está listo para usar. Pero todavía necesita ser utilizado . Sin eso, el componente permanece inactivo en la carpeta de componentes.

12. Incluya este componente en el archivo de plantilla requerido (este es el archivo html.twig debajo de la carpeta de plantillas en el tema personalizado) con formato [theme_name:component-name]. Observe la declaración de inclusión en la que agregamos las variables twig que se utilizarán en el componente.

13. El componente ahora se renderiza con nuestro nuevo marcado y mejor estilo.

14. Fíjese en el marcado. Si la depuración de twig está habilitada, también obtenemos algunos íconos especiales con nuestro componente SDC renderizado.

¡Y eso es!

Referencias

• https://www.drupal.org/docs/develop/theming-drupal/using-single-directory-components/about-single-directory-components
• https://www.drupal.org/project/sdc
• https://herchel.com/articles/creating-your-first-single-directory-component-within-drupal

Pensamientos finales

Con la forma en que se ha construido SDC, habrá un desarrollo de alta intensidad a su alrededor. Una de las pistas populares es que los módulos detectarán automáticamente los componentes e insertarán sus respectivos formularios en Layout Builder, CKEditor, Paragraphs, Blocks, Fields, etc. Además, SDC en este momento funciona bien con Storybook a través de un módulo contribuido llamado CL Server (que ha sido mantenido por los mantenedores del proyecto SDC). Ya hay otros módulos como CL Devel, CL Generator e incluso UI Patterns que se están construyendo alrededor de SDC.

Esto también nos ayudará a actualizar nuestro propio generador de temas (Drupal Theme Init) que discutimos anteriormente para brindar la opción de usar SDC junto con un sistema de diseño en su lugar, preferiblemente Storybook. Esto ayudará a cualquier persona a iniciar la implementación de SDC al instante, allanando el camino para un mejor desarrollo de temas.

Si desea leer más contenido interesante sobre Drupal, ¡suscríbase hoy a nuestro boletín semanal!