Como trabajo yo el frontend en Drupal

 Hola, otra semana más aquí en Drupalizate. Hoy te quiero comentar cómo trabajo yo el tema del front-end, sobre todo cuando es un front-end, o la parte visual de la web, para quienes no sepan qué es el front-end, de webs que empiezo yo desde cero, o sea, proyectos nuevos. Es una historia completamente distinta cuando el proyecto ya está empezado por alguien que no es yo, un freelancer o otra agencia, que cada uno tiene sus formas de trabajar y al final te tienes que adaptar a cómo está hecho hasta este punto el diseño. Normalmente cuesta mucho de si el diseño estaba hecho de una forma... No, pues ahora lo hará de otra. Y al final tienes un código para ti, tienes que intentar siempre mantener la misma estructura de cómo se estaba trabajando hasta este momento. Así que yo me voy a centrar en este episodio a cómo lo hago yo desde cero. Primero de todo, para que se entienda, hay una persona que es un diseñador, que no pica código, digo entre comillas, solo, tiene buen gusto visual y diseña cómo se debe ver la web. Después hay otra persona que es el de front-end, que aquí me incluyo yo, que le pasan un diseño en formato imagen, o imagen o Photoshop o en otras herramientas, que básicamente es, aquí tienes una imagen, quiero que la web se vea igual que esta imagen. Hace el código del front-end de HTML, JavaScript, CSS para que se vea igual, en plan pixel perfect, que es que se vea idéntico. Si no es pixel perfect, que la llaman, es que bueno, que se parezca más o menos. Normalmente cuando trabajas para agencias te piden que se vea idéntico a lo que te ha pasado el diseñador. Dicho esto, el diseñador y la persona de front-end han de ir muy de la mano, porque si el diseñador piensa en reutilizar cosas, cuando digo cosas por ejemplo son elementos, que todos los botones de la web tengan el mismo estilo visual. Si después la persona de front-end no reutiliza el mismo código, sino que lo va duplicando por todas partes, digamos que no va muy de la mano. Y lo mismo la inversa, si el programador no puede reutilizar el código porque cada diseño de cada página de la web es totalmente distinto y no se aparece en nada un botón de la home con un botón que aparece en el blog, pues mal vamos. Así que, ha de tener buena comunicación el diseñador y la gente de front-end, o al menos trabajar de forma similar. Y aquí voy con el tema de reutilizar cosas. Para tener un menor coste y sobre todo para trabajar más rápido, es de lógica que se reutilicen cosas. Y con cosas me refiero a que si tenemos un listado de tags, si ese listado de tags se muestra en la home, en el blog, en el teaser del artículo del blog y en otras páginas, que en todas partes se vea de la misma forma. Que si tenemos un botón o varios botones que sean siempre del mismo estilo visual con el mismo color, con el mismo sombreado, con los mismos efectos de hover, por ejemplo, y al final es que toda la web tenga un mismo estilo visual y que sea consistente en todas las páginas. Porque he visto webs que no son consistentes, que el diseñador, una página la ha hecho con un color, otra página la ha hecho con otro color o con unos tamaños de fuente distintos. Por ejemplo, los tamaños de fuente, que todos los títulos H1 de las páginas tengan el mismo estilo visual, el mismo tamaño, el mismo interlineado y una ubicación en la página digamos similar, que si las páginas siempre están arriba, pues que siempre esté arriba. No que una página esté arriba, en otras esté en un lateral y en otras no esté. Que también me lo han contado. Bueno, total. Para hacer cosas reutilizables, se ha puesto de moda, o ya se puso de moda hace un tiempo, que son los diseños atómicos, el Atomic Design. Básicamente es un diseño basado en componentes y la reutilización de esos componentes. Comentame, tenemos un botón. Mejor dicho, tenemos la Home. La Home tiene un componente que es imagen de cabecera o banner de cabecera, que incluye un componente de imagen, un componente de botón y un componente de título. Pues el componente de botón que se usa en este banner de cabecera, será el mismo componente botón que se va a usar en el formulario con el botón de submit. Con lo cual, una vez diseñado ese botón, se reutiliza todo el mismo código para todos los botones. Como mucho, puedes tener variaciones. Pues que habrá un botón que será con color de fondo primario, o sea, por ejemplo, el color de la web. Y un color de fondo secundario. O sea, puedes tener variaciones, o botones pequeños y grandes, que sólo varíais el tamaño de fuente, por ejemplo. Y lo mismo con títulos. Los títulos serán siempre con el mismo tipo de fuente y lo que variaría, lo que variaría, que me piso la lengua, es sólo el tamaño de fuente y el interlineado. O sea, H1, H2, H3 vendrán a ser lo mismo y básicamente cambiaran cuatro cosas. Pero no sean hiper distintos, con distinto tamaño de fuente, con distinto color, con distinto interlineado, porque al final no puedes reutilizarlos en todas partes. Todos los H2 tendrán el mismo estilo visual en toda la web. Esto en la parte más de frontend, ¿cómo se puede trabajar? Y concretamente en Drupal, ¿cómo lo trabajo yo? A ver si me se explica. En Drupal, digamos que tenemos tres cosas importantes a tener en cuenta. La primera es que todo el CSS lo puedes meter en un solo fichero o en varios. Al final, los fichos CSS que tengas, ya sea solo uno o varios que tengas, los pones en un fichero que es el Libre.js y aquí especificas que el tema visual de Drupal cargue las librerías que has creado. Puedes tener, como digo, una sola librería con un fichero CSS, con todo ahí puesto, un fichero que pesará relativamente bastante. O puedes separarlo. Que por ejemplo tengamos, a ver para que se entienda, el CSS que se usa para el el menú que está en todas las páginas será la librería lo que venga del menú. Después tenemos un CSS que solo se usa en los formularios, pues podemos tener una librería de formularios. Y ya no solo CSS, podemos tener también el JavaScript y tener una librería que incluya el CSS y el JavaScript para determinados componentes. Al final es un poco más complejo de configurar porque tienes que tener bastantes librerías separadas y después incluirlas o para que se carguen siempre desde el tema base en Drupal o para que en cada plantilla que Drupal usa Twig, pues en las plantillas Twig puedes incrustar también decirle que esta plantilla usa esta librería. La ventaja de esto, y por cierto también se puede usar desde código PHP, de que por ejemplo cuando rendeis un formulario te cargue esa librería. Y que no haga falta modificar una plantilla Twig, sino que directamente el PHP de Drupal va a cargar por detrás la librería. ¿Por qué es útil tenerlo en librerías separadas? Primero por rendimiento, porque tienen los ficheros separados en ficheros más pequeños y si una página no tiene un formulario, pues no va a cargar ni el JavaScript ni el CSS del formulario, con lo cual te ahorras tiempo de entrega. Si por ejemplo la home solo tiene el menú y una imagen muy grande y no tiene más elementos, pues va a tener poco CSS, porque no va a cargar el CSS del blog, no va a cargar el CSS del formulario y no va a cargar el CSS de otros elementos. Imaginemos si sabes un poco más de Drupal y de los paragraphs que lo comenté en episodios pasados, puedes crear librerías de CSS que se usan en determinados paragraphs y solo cargarlas para cada uno de los elementos paragraph. Con lo cual si tienes una landing que usa solo dos tipos de paragraph va a cargar solo las librerías de esos dos tipos, no va a cargar los 20 tipos de paragraph y sus librerías. Al final te ahorras tiempo y le ahorras el tema de descarga de datos al usuario que está mirando tu web. Así que por SEO, o sea por rendimiento de descarga, es bueno y dicen de que sí que se nota algo en temas de SEO. En la práctica, bueno si tienes unos fichos muy grandes, sí, recomiendo hacerlo, pero en la práctica muchas webs digamos que ignoran esto de tener muchos pero muchos fichos separados. Tienen un par o tres, por ejemplo los que queremos priorizar como los de la cabecera, los que son paragraphs por separado y los que son formularios o secaeditos por otro. Al final tienes unos pocos ficheros separados, no tienes 20 ficheros distintos, porque al final tampoco aprovechas tanto esto. Lo que sí que recomiendo es, sobre todo cuando trabajas en Boost.Ruby y con Sass, tener ficheros Sass para cada uno de los componentes, que después se van a compilar y se van a juntar todos en un único o en dos o tres ficheros CSS en vez de tener 20. Pero la forma de trabajar de tener un Sass pequeño para cada componente, pues los botones tendrán un Sass, el formulario de la home tendrá un Sass que va después, se ve como lo explico, vas a intentar no tener un fichero Sass con todo puesto allí que después de un mes cuando te lo que modificado a ti u a otra persona se va a volver loco porque no sabes si eso va a afectar a otros componentes o no. Dicho de otra forma, intenta no poner clases CSS que afecten a lo que es un nodo, el node, todo lo que sea node va a tener ese estilo visual y después cuando es un node tipo page lo sobrescribo para que con importance se vea un poco distinto. Es un no no. Cuando sea un node tipo page tiene este CSS, cuando sea un node tipo blog tiene este otro CSS y no vayas sobrescribiendo a saco y aún menos metiendo importance. No sé si me estoy explicando bien pero al final es una forma de trabajar de intentar tenerlo todo separado en fichos más pequeños y sobre todo esto es muy útil, al menos a mi me ha sido útil cuando trabajas con más gente porque puedes separar las tareas, o sea cuando tienes a vaya gente en frontend puedes decir, yo me ocupo de lo que está en la home, tú te ocupas de lo que está en el blog y al final el que está en el blog tendrá un fichero sas para el campo imagen del blog, el campo tag que está en el blog, cómo se muestra el node en formato teaser en el blog, cómo se muestra el campo node en formato bimod de full y solo que afecta al blog y la otra persona se va a ocupar de lo que está en la home. Y esto es muy útil porque como tenemos fichos separados no nos pisamos cuando trabajamos con Git. Si tuviéramos un único fichero tendríamos varios merge siempre del mismo fichero. De esta forma cada uno tiene sus propios ficheros y si lo tenemos ordenado por directorios en plan de todos los fichos sas que son de campos están dentro de filter, todos los fichos sas que son de nodos están dentro de node. Intentar tenerlo ordenado separado por componentes. Y con el tweak, o sea las plantillas html tres cuartos es lo mismo. Estoy trabajando mucho más con plantillas tweak ahora que uso Talwin que no con BoostApp, que se puede trabajar de misma forma pero al final con BoostApp siempre puedes machacarlo más del CSS que no es de plantilla. Con Talwin como mucho del CSS son clases que se ponen en el mismo html pues al final te obliga en cierta medida a trabajar con plantillas tweak y tienen muchas plantillas. La parte buena es que puedes incluir plantillas entre plantillas y extenderlas. Y al final es una forma de hacer un Atomic Design de forma forzada. A mi casi que me va mejor. Con lo cual puedes tener un directorio, si lo tienes todo ordenado, un directorio de plantillas con su directorio de nodo dentro de su directorio de el tipo de nodo y dentro si lo quieres separar por bimodos o no. El node block tiene las cuatro plantillas todas una a la otra. El bimo de full, el teaser, lo que se muestra en el sidebar y lo que toque. Si quieres quedar tantos bimodos como te hagan falta por tu diseño. Y para campos lo mismo, tenemos un directorio tweak con las plantillas de los campos y dentro lo podemos separar por los campos que son de formularios, si es que no tenemos un directorio directamente para los formularios o podemos separarlo por tipos de campos, si son campos numéricos, campos de taxonomía, campos de lo que sea. Al final es una forma de trabajar intentando tenerlo todo ordenado porque cuando estás tú solo sí que es más o menos fácil de, bueno, pues lo pongo todo junto y ya está. Pero cuando trabajas con más gente, o ya no con más gente sino de que de aquí a seis meses te va a tocar a ti mismo modificar cosas y no te vas a acordar cómo estaba hecho. Si tienes una estructura y siempre trabajas más o menos en la misma forma teniéndolo más o menos ordenado, te es más rápido aplicar estos cambios y sobre todo que no afecte a cosas que no debían afectar. Que si modificas el color del botón del formulario que no te afecte pues al color del texto que se ve en el formulario. Al final intentas tenerlo lo más compartimentado posible. Y bueno no sé si ha quedado más o menos bien explicado este tema. Puesto que yo intento trabajar en una forma similar aunque no es 100% fiel a lo que es el concepto de Atomic Design. Y que intento tener en cuenta siempre si otra persona tiene que venir en el futuro y meterse a trabajar conmigo en Frontend, ¿va a entender cómo está montado todo esto? o es un espagueti de código que para ir rápido lo he hecho de esta forma. Yo intento siempre tenerlo más compartimentado y que no haga falta excesiva documentación para tenerlo. Si ya ves que hay un directorio con su directorio de campos, nodos y tal, se entiende pues que los fichos que afectan a los nodos están aquí. Si los fichos que afectan los campos están allí. No hace falta documentar dónde está cada cosa porque se entiende. Y nada más. Hasta aquí este episodio. Espero que haya sido útil que no lo den claro porque ha sido de imprevisto este episodio. Hasta la siguiente semana.