Viaje de inicio al laboratorio de patrones Drupal +

Pattern Lab es un tema candente en la comunidad Drupal hoy en día, ofrece muchas ventajas y promete vida fácil para diseñadores, clientes y finalmente para desarrolladores. Siendo modernos e innovadores, nuestro equipo seguramente no podía pasar, así que vimos y leímos varios artículos sobre y llenos de emoción lo trajeron al próximo proyecto. Sin embargo, una cosa que noté fue que la mayoría de los presentadores tenían un conocimiento significativo de Drupal, que no era mi caso, pero no presté atención en ese momento.

Hay 3 razones por las que nos gustó Pattern Lab y las analizaré compartiendo lo que descubrimos y sobre las cuales debes prestar atención mientras adoptas la tecnología .:

  1. Enfoque basado en componentes
  2. Desacoplamiento frontend y backend para que frontend pueda funcionar sin conocer las agallas de Drupal
  3. Parque infantil de la biblioteca de patrones agradables que se puede mostrar al cliente / diseñador para una revisión temprana

1. Enfoque basado en componentes

Con el aumento de frameworks de frontend como React, Angular 2+, Polymer y muchos otros es difícil imaginar una arquitectura front-end basada en componentes que en resumen significa que cada componente tiene su propio alcance para la lógica de datos, vista y controlador, que son normalmente se presenta con JS, CSS y JSON o YML, lo que significa que los cambios dentro de un componente no afectarán los estilos y la lógica interna de los demás.

Entonces el componente normal se ve así:

Pattern Lab recomienda agrupar activos en carpetas según la metodología de diseño Atomic y proporciona un gran soporte para los datos ficticios aislados de los componentes que nos dan la libertad de elegir nuestras propias herramientas para manejar el alcance JS y CSS, lo cual es una jugada inteligente en el sentido de que no pueden predecir pila preferida que normalmente usamos para eso.

HTML : no hay muchas complicaciones sobre el alcance de HTML, así que simplemente creamos una plantilla twig propia para cada componente y luego la usamos donde queramos a través de las directivas include e embedded twig que pasan los valores de parámetros apropiados.

Datos de componentes: podemos elegir el formato JSON o YAML para los datos ficticios de los componentes. Ambos son geniales y hay formas fáciles de migrar rápidamente de uno a otro, aunque elegimos YAML ya que se ve más limpio:

JSON vs YAML ejemplo

Estos archivos se utilizan únicamente para representar componentes en la interfaz de usuario de Pattern Lab y nunca aparecen en la producción. Podemos establecer múltiples instancias de datos ficticios para cada componente simplemente modificando el nombre del archivo postfix separado con el símbolo de tilde, lo que lo hace super útil para probar y demostrar diferentes estados del componente.

Estructura del archivo de datosEjemplo de diferentes estados de componentes

Hay un archivo de datos global al que se puede acceder a través del árbol de componentes, por lo que es una buena idea colocar, por ejemplo, elementos de menú globales o enlaces de pie de página. pattern-lab/source/_data/data.yml se puede acceder al archivo de datos global desde esta ubicación: pattern-lab/source/_data/data.yml .

Precaución : los únicos datos que se utilizan para representar un componente son sus propios datos y datos globales. Si incluimos o incorporamos el componente_1 dentro del componente_2, tenemos que poner los datos para el componente_1 en el archivo de datos del componente_2. Si desea evitar ese trabajo manual, consulte este complemento: Complemento de herencia de datos .

CSS : usamos la combinación SCSS + SMACSS + BEM que nos dio una forma de aislar CSS a través de la convención de nomenclatura de clases. No entraré en detalles aquí pero puedes echar un vistazo a algunos trucos de SCSS para lograr esto. También estoy esperando módulos CSS para proyectos futuros.

JS : es la parte más complicada y se divide en varias tareas.

Módulo de paquete : Drupal 8 de forma predeterminada proporciona una forma muy buena de adjuntar CSS y JS de componente a la página introduciendo un concepto de biblioteca que permite especificar diferentes paquetes en la configuración de Drupal y luego incluir solo aquellos en la página que realmente se requieren. Una definición de biblioteca puede verse así:

Y luego tiene que ser adjuntado a la plantilla por cualquiera de los métodos descritos en la documentación aquí .

El problema puede aumentar si accordion.js de nuestro ejemplo tiene su propia dependencia en el interior. No es una buena idea simplemente poner esta dependencia en el mismo nivel en el archivo de configuración porque en este caso tenemos que copiarlo en todas partes. Y si hay varios niveles de dependencias, las cosas se vuelven muy confusas.

Para resolver esto usamos Browserify viejo y bueno , y Webpack también puede ser una opción. Para hacerlo funcionar, solo require módulo dentro de nuestro archivo JS y dejar que Browserify lo maneje por nosotros a través de una tarea gulp . Así es como comienza nuestro archivo javascript de componente de overlay :

Otro problema es que Pattern Lab no sabe nada sobre el concepto de las bibliotecas Drupal y, si queremos que nuestros componentes funcionen dentro de su entorno limitado, debemos agregar todas las mismas bibliotecas en el archivo pattern-lab/source/_meta/_01-foot.twig para asegurarnos nuestro JS es accesible en todas las páginas dentro del entorno de prueba.

Para simplificar las cosas al principio, simplemente creamos un gran paquete de JS y lo adjuntamos tanto a Drupal como a Pattern Lab. Afortunadamente pudimos mantener el paquete relativamente pequeño y no había mucho espacio para dividir JS entre páginas, por lo que nuestra solución temporal se volvió permanente 🙂

Interacción de componentes : una vez que tenemos todos los componentes aislados, tenemos que definir una forma en que se comunican entre sí.

Imagine que tenemos un componente de encabezado y un menú de barra lateral que se desliza en cualquier momento que se presione el botón en el encabezado.

Podríamos hacer la lógica directamente dentro del encabezado JS (dentro de un controlador de evento click) pero tan pronto como nos esforzamos por una arquitectura débilmente acoplada , decidimos ir con un patrón de mediador simple en su lugar y elegir Redux . Es bastante popular y cubrí algunos de sus aspectos antes.

Una cuestión que no debe olvidarse es que Redux llama por defecto a todos los suscriptores de la store lo que no queremos que ocurra porque no tenemos un DOM virtual y un inteligente mecanismo de detección de cambios aquí como React, así que usamos una extensión llamada redux-watch y envuelve nuestro método de subscribe de la forma en que solo se invoca el reducer requerido:

Si la terminología suena confusa, la documentación de Redux puede ser útil.

Comportamientos de Drupal : si nunca trabajó en proyectos de Drupal, debe familiarizarse con el concepto de comportamiento de Drupal . En resumen, en el mundo de Drupal no podemos confiar en ningún evento de carga de documentos porque cualquier momento en que Drupal a través de AJAX pueda reemplazar cualquier parte de HTML con la versión nueva del mismo y la única manera que conozcamos es a través de la attachBehaviors método attachBehaviors .

Así que la regla general aquí:

Siempre envuelva su código JS con el objeto Drupal.behaviors.yourName

Ejemplo de comportamiento

Aunque Pattern Lab no sabe nada sobre behaviors y tenemos que adjuntar manualmente drupal.js desde el núcleo de Drupal a todas nuestras páginas de Pattern Lab dentro del archivo pattern-lab/source/_meta/_01-foot.twig :

Código para drupal.js adjunto

Junto con ready.js . Esto ya está incluido en el tema Emulsify Drupal, que trataré más adelante, por lo que probablemente solo deba descomentar las líneas de código correspondientes.