Programando un blog desde 0. #3 Maqueta 4


Una vez listo el diseño, el siguiente paso es implementarlo como una estructura html y una hoja de estilos. Esta estructura será nuestra maqueta a la cual más tarde proveeremos de datos y manejadores para hacerla interactiva y convertirla en una aplicación. Podría parecer que estamos realizando el doble de trabajo al implementar el diseño en Gravit (o Sketch, Framer, Illustrator, etc) y después en html. Pero en realidad contar con medidas, fuentes, colores, etc de antemano acelera muchísimo el desarrollar tu css y html. Además desarrollar esos patrones en una aplicación de diseño es mucho más rápido que en CSS. Y te ahorra el tedioso ensayo y error de implementar un diseño directamente al navegador. Así que en el cómputo global, esta técnica es la más efectiva. No en vano, profesionalmente nadie diseña directamente en html y css.

Preambulo

En esta entrada voy a describir el proceso que he realizado para estructurar mi proyecto, descomponer el diseño en componentes e implementar en React componentes tontos o funcionales, a los que luego pueda dar comportamiento a traves de propiedades.

Stack

Si estás en el mundillo del desarrollo web, sabrás que desde hace unos años existe una guerra abierta entre los defensores del css-in-js y los apóstoles de la cascada. Básicamente los primeros opinan que css está roto y nació obsoleto, haciendo complicado aislar tus estilos y caótico controlar qué está afectando a quien. La soluciones propuestas parten de la premisa de que dar estilos a nivel de componente es más fácil y lógico si lo hacemos mediante JS. El segundo grupo aboga por que esas soluciones son antinatura, que nacen de la frustración de los que no quieren/pueden aprender a hacer css bien, que el css-in-js afecta negativamente al performance (cosa que es cierta), que además rompe la separación de responsabilidades y como colofón que la web funciona de una determinada manera y que los experimentos mejor hacerlos con la gaseosa.

Yo me encuentro en mitad del espectro: Opino que css es como es por una razón y que si no le saco mas partido a la cascada es por falta de conocimiento. Pero a la vez, creo que en determinados proyectos utilizar alternativas puede resultar satisfactorio e incluso beneficioso y que el coste extra en performance no es siempre apreciable. Por tanto, no siempre existe una razón para descartar css-in-js y las ventajas son obvias. Siendo este es el caso, decidí introducir styled components en mi proyecto. El beneficio que buscaba no era otro que el dar estilos a nivel de componente me ayudaría a, valga la redundancia, componentizar mis estilos. Y con ello mantener cierto orden en mi sistema de componentes. A parte, es una librería que me gusta mucho y en Redradix no puedo utilizarla, puesto que los desarrolladores no maquetamos. Así que me quité la espinita con este proyecto.

Por otro lado, he intentado seguir los principios del diseño atómico para, una vez más, mantener el orden y la coherencia en mi sistema. Si bien no es un elemento del stack tecnológico, si que considero adoptar atomic design como una decisión técnica por todo lo que implica en el desarrollo. Como puedes ver, estructurar y organizar el sistema de componentes es una de las disciplinas que más me cuestan, a mí y creo que a todos los que nos dedicamos a esto desde el espectro de la lógica más que de él del diseño o lo visual. De ahí que me haya apoyado en styled components y atomic design. A lo largo de esta entrada podrás ver qué decisiones tomé en este sentido y a qué puertos me han llevado.

Desarrollo de la maqueta

Atomic design

Como he mencionado, partí de la premisa del atomic design. Cree una carpeta ui donde se concentraría toda la parte visual de mi aplicación, aislada de la parte lógica:

Estructura de carpetas del proyecto

Estructura de carpetas del proyecto

La misma se subdivide en 4 apartados, conforme a la jerarquía de atomic:

Atoms/Átomos

Hace referencia a la naturaleza indivisible de los mismos. El átomo es el componente más pequeño en el que puedes descomponer tu sistema. En un escenario ideal, todos los componentes de las otras carpetas habrían de estar compuestos de un conjunto de átomos. El ejemplo más claro de un átomo sería un icono. En el siguiente ejemplo se define el átomo del título de la entrada, en la cabecera de la misma:

Titulo de la entrada como átomo

Titulo de la entrada como átomo

Como se puede observar, definir átomos con styled components (a partir de ahora, SC) es pan comido: Importar la clase y utilizar la función constructora correspondiente al tag html qué queramos utilizar. Si no has dado antes con ella, la notación que va desde la línea 4 hasta la 10 te puede resultar muy confusa: Parece css. va dentro de un string template, invoca a props en las líneas 5 y 6… Es parte de la magia de SC. Si te interesa ver como funciona, te remito a esta entrada en el blog de su creador, donde explica qué son y cómo funcionan los tagged template literals y cómo los usan en SC. 

Algunos ejemplos de atomos

Algunos ejemplos de atomos

En esta imagen se señalan algunos ejemplos de lo que serían átomos: Elementos sencillos, que no se pueden descomponer y que se pueden reutilizar por toda la interfaz.

Molecules/Moléculas

En el siguiente orden vendrían las moléculas. Tal y como yo las entiendo, serian agrupaciones de atomos que, a diferencia de estos, aportan sentido en sí mismas: Por ejemplo, un icono por sí mismo no es más que una imagen, pero un icono junto a una etiqueta de texto en un determinado lugar nos indica que se trata de una opción de un menú. Una vez mas, en un escenario ideal todas las moléculas serían composiciones de átomos. Sin embargo, en ocasiones molécula y átomo son el mismo elemento puesto que la primera se compone de un solo elemento. Es el ejemplo de los tags que señalo en la anterior imagen, que no son más que un texto con fondo de color. En esos casos he optado por degradar estas moléculas a átomos.

Ejemplo de molécula

Ejemplo de molécula

En el ejemplo, el código que describe cómo es el encabezado de la entrada (el bloque donde se encuentra título y subtítulo de la misma). En todas la moléculas hago uso de un componente auxiliar que define el Layout de la misma: Cómo se ordenan y como se ve el contenedor de los átomos que lo componen. Se podría opinar que este layout constituye un átomo en sí, pero en mi caso he decidido que no lo sea puesto que este componente no tiene sentido fuera de la propia molécula. Este patrón de layout+átomos lo he usado en toda la aplicación.

Ejemplos de molécula

Ejemplos de molécula

En la imagen se señalan algunos ejemplos de molécula: Conjuntos de elementos que aportan significado por sí mismos y que agrupados forman…

Organisms/Organismos

Los organismos establecen una jerarquía por encima de las moléculas: Agrupaciones de estas que definen partes concretas de una aplicación y definen su funcionalidad. Por ejemplo, un menú de navegación sería un organismo formado por una serie de moléculas que definen cada una de las opciones de dicho menú y define la forma de moverse por las distintas secciones de la misma. Volvemos a un escenario ideal: En el mismo, un organismo no podría ser compuesto por atomos y moleculas, solo por estas últimas. Pero como digo la teoría es bastante más fácil que la práctica y trasladar esto a código te suele llevar a situaciones en las que te saltas estas premisas. Es decir, que recurres a meter átomos en los organismos.

Ejemplo de organismo

Ejemplo de organismo

No es el caso de este ejemplo. En el se ve claramente como un layout envuelve a una serie de moléculas para formar el organismo que define el menú de interacción con la entrada.

Ejemplos de organismo

Ejemplos de organismo

En la imagen se señalan los organismos de la página: Básicamente, secciones independientes que aportan funcionalidad a la misma.

Templates/Plantillas

Una plantilla es un conjunto de organismos que define una vista de tu aplicación/página. Regresando a la última imagen, borra mentalmente los cuadrados azules y veras la plantilla que define cómo se ve una entrada en mi blog. Otra plantilla podría definir como se ve el portafolio, otra la página de contacto, etc.

Ejemplo de plantilla

Ejemplo de plantilla

En este ejemplo se ve lo sencillo que es definir una plantilla: Simplemente, una colección de organismos. Una vez aportados los datos mediante componentes de alto orden, la plantilla tendrá la responsabilidad de hacer llegar datos y manejadores via props a los organismos. Dado el enfoque usado con los SC, el prop drilling solo tendrá cuatro niveles (puedes leer que es y que problemas produce aquí), por lo que el modelo de datos será siempre manejable gracias a que hemos adoptado atomic design. Como ves, SC no se trata de una librería o tecnología pero el impacto técnico en la aplicación es de primer nivel.

Mixins

Fuera de los que sería atomic design en si, he utilizado unos pocos mixins para describir estilos que se repiten entre componentes que no se pueden considerar átomos o moléculas:

Mixins

Mixins

Son solo dos, pero la idea es ir analizando la aplicación conforme crezca e ir abstrayendo estilos que se repitan en mixins. En realidad el concepto de mixin choca frontalmente con el de componentización, por lo que se debe usar con cuidado si no se quiere acabar con un pastiche inmanejable. Idealmente, se deben abstraer en atomos/moleculas aquellos comportamientos visuales que se repitan.

Sistema de iconos

Dentro de los átomos existe uno en particular que tiene una importancia superior a los demás: El sistema de iconos. Este permite mostrar pequeños logotipos que refuerzan mediante imágenes el contenido de la página y mejorar su aspecto y usabilidad. Un buen sistema de iconos debe permitirte invocarlos de una forma sencilla para decorar tu página, sin afectar al performance, a la maqueta o a la carga de datos. A lo que me refiero es que implementar un sistema de iconos es más complejo que utilizar un tag img con el src apuntando a ficheros estáticos.

En mi caso partí de la siguiente premisa:

  • Debía utilizar un formato vectorial que me permitiese redimensionarlos sin aliasing.
  • Debía permitirme modificar sus propiedades en tiempo de ejecución, incluyendo el color.
  • Los assets a utilizar (las propias imagenes) debian ser ligeras para evitar que mi página haya cargado pero mis iconos no.
  • Debía poder crear y modificar iconos con gravit.

El formato svg me permitía hacer esas cosas y muchas mas, por lo que decidí ceñirme a el. El punto de entrada es el componente Icon:

Componente Icon

Componente Icon

Revisando cada una de las partes del archivo:

  • En las cuatro primeras líneas importo las dependencias del componente. Entre ellas se encuentra Icons, que no es más que un objeto cuyos valores son componentes, cada uno de ellos conteniendo un icono en formato svg/jsx
  • Entre la sexta y la duodécima, defino el wrapper o contenedor que va a envolver siempre al icono. Aquí defino qué reglas se le van a aplicar en función de las props, como por ejemplo el fill, que define el color del icono. También defino una transición para todas las reglas (linea 12), por lo que simplemente cambiando estas props se produce automáticamente la animación del componente.
  • Entre la 15 y la 17, defino el color por defecto, para cuando no pase esta prop.
  • Entre la 19 y la 26 defino el componente en si. Este lee la prop type y rescata el icono con ese mismo nombre del objeto que importé en la línea 4. Si no existe o no se ha pasado un type, utilizo el icono ‘logo’ por defecto. En la línea 22 inyecto las props al SVG y en la 23 renderizo el icono deseado.

Y con este sistema tan sencillo, podemos invocar un icono tan facil como:

Ejemplo de invocación de icono

Ejemplo de invocación de icono

Para generar los iconos, los creo en Gravit o los descargo de flaticon o similar, los exporto a svg y copio el contenido en un componente React dentro de un Fragment, cambiando la notacion html (pej. fill-opacity o class) por notación jsx (fillOpacity o className). He aquí un ejemplo:

Ejemplo de icono

Ejemplo de icono

En la siguiente imagen se ve como exportar un objeto que exponga cada uno de los iconos:

Colección de iconos

Colección de iconos

Y eso sería todo. Un sistema flexible, muy facil de expandir y configurable en tiempo real. Antes de iniciar este proyecto ponía todos mis huevos en la cesta del png o las custom fonts para los sistemas de iconos. Pero svg me ha demostrado una potencia y versatilidad increibles y te recomiendo que lo pruebes en tu próximo proyecto. Create-react-app V2, que ha salido hace una semana, permite importar svg directamente, así que está más a huevo que nunca.

Evolución de la página

A continuación os muestro como fué creciendo la app desde una pantalla en blanco hasta el diseño final. Empecé por la parte de la cabecera de la entrada, con títulos, icono e imagen de fondo.

Añadí después el header, con el isotipo 

Seguido de la barra de metadatos de la entrada:

Para seguir con el cuerpo de la misma, con meros placeholders.

A continuación les dí a estos estilos definitivos, introduje los dos menús de navegación y opciones de entrada y terminé el header con los tabs y los links sociales.

Finalmente, ajusté las sombras, añadí el copy, realicé innumerables ajustes e introduje la textura granulada al fondo de la página:

Con algunos matices, el resultado se parece bastante a lo que teníamos en la anterior entrada.

Septima itración

Septima iteración

Conclusiones

Esta parte del proyecto se me ha hecho bastante pesada. Desde el principio he tenido la tentación de introducir comportamiento a los componentes y me he tenido que aguantar y seguir trabajando en estructura y aspecto. Pero ceñirme al plan y trabajar en generar los assets me está permitiendo ahora desarrollar a una velocidad muy alta sin preocuparme de cómo se ven las cosas. De ese modo, no tengo que estar cambiando el chip entre el modo css y el modo react. Es la forma en la que trabajamos en Redradix, y realmente funciona.

Por lo demás, me hubiese encantado componentizar mejor, hacer un uso más eficiente del potencial que ofrece styled components, utilizar un loader de webpack para no tener que meter los svg a mano… Muchas cosas. Antes de que aparezca algún hater por los comentarios, soy muy consciente de lo limitado de mi conocimiento acerca de atomic design o sistemas de diseño. Simplemente he tratado de invertir el menor tiempo posible en aprender la disciplina al punto que me permita desarrollar mi idea tal y como me propuesto. En cualquier caso, creo que el resultado hace honor al diseño que se planteó y cumple con la premisa de trasladar aquella idea vectorial a componentes jsx. Todo el código generado sigue a mi disposición para ir mejorándolo en siguientes capítulos. Y en el proceso he aprendido muchísimo sobre cómo abordar este tipo de tareas, por lo que en el futuro podré afrontarlas con mejores armas.

Todo el contenido desarrollado en esta entrada está disponible dentro del repo del proyecto, en la rama chapter-3. Si tienes curiosidad, puede echarle un vistazo al código del capítulo 4, que ya estoy terminando, checkeando la rama chapter-4. En la próxima entrada explicaré cómo empiezo a proveer de datos a la maqueta y como genero las primeras interacciones.

Por último, comentar que he empezado con el reto de #100DaysOfCode, por el cual me he comprometido conmigo mismo a programar al menos una hora al día en proyectos personales durante, en principio, cien días (ya llevo 16). Por lo que el desarrollo se ha acelerado de manera bestial y a consecuencia espero alcanzar un ritmo de publicación de dos entradas al mes. Y tener una primera versión del nuevo blog antes de final de año. Si te interesa, puedes leer sobre el reto en la página oficial www.100daysofcode.com y apuntarte al mismo. Te aseguro que merece mucho la pena. Si quieres seguir mis progresos, estoy twiteando los mismos diariamente con el hashtag #100DaysOfCode.

Y nada mas, nos leemos en la próxima 😉


Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

4 ideas sobre “Programando un blog desde 0. #3 Maqueta

  • Alberto

    Como puedo ir comprobando que los elementos que voy creando los estoy haciendo correctamente ?

    Por ejemplo he empezado creando el header de mi página que se va a mostrar siempre, como hago para que cuando ejecuto el servidor de desarrollo en mi pantalla home comprobar que todos lo que he estado creando tanto atomos, moleculas etc . los estoy creando bien ?

    Un Saludo y espero el siguiente capitulo !!!

    • Fran Autor

      Hola Alberto!

      No termino de comprender a qué te refieres. Crear los componentes «bien» es algo subjetivo por lo que debes ser tu el que decida el camino a seguir. Si lo que te pasa es que los componentes no se muestran, me temo que te has tomado esta entrada como un tutorial y no es el caso. Para que se muestren debes montarlos en un componente home que sea renderizado por ReactDOM… pero ya te digo que la intención de esta entrada no es explicar pormenorizadamente como se escribe una aplicación React, simplemente contar a grosso modo como voy desarrollandola. En cualquier caso, tienes todo el código disponible en github aquí y si buscas un poco por google darás con miles de tutoriales para iniciarte con React y montar tus primeros componentes.

      Si es ese el caso, olvida Styled Components hasta que tengas algo de soltura con React.

      Un saludo!

  • William Ramirez

    Estimado Fran, he estado leyendo tu post por encima para después digerirlo como se debe hace poco que llevo en esto del desarrollo web y acabo de terminar de entender medianamente bien redux, mi pregunta es la siguiente, desde que entre a este mundillo lo que mas he escuchado y recomiendan es practicar, practicar y mas practica como en cualquier otra disciplina lo que me lleva a una duda siguiendo esta serie post, podría alguien como yo recién empezando en el mundo desarrollo web hacer el blog que creas en estas entrada. Un Saludo

    • Fran Autor

      Buenos dias William, disculpa la tardanza.

      Pues cada persona es un mundo. Por poder, si le echas horas, te documentas, aprendes las tecnologías… puedes desarrollar lo que te de la gana. Lo normal es que no llegues a ningún sitio, pero por el camino aprendas bastante. No sé, sinceramente es una pregunta absurda: «Acabo de empezar la carrera de arquitectura ¿Podría diseñar un rascacielos?» Pues eso. Sigue practicando en los proyectos que te gusten, que el objetivo es siempre aprender.

      O a lo mejor he entendido mal tu pregunta y me estas preguntado acerca de si esta entrada es un tutorial qué puedas seguir. NO. No es un tutorial, no está pensado para que programes mientras lo lees, simplemente que lo leas y aprendas un par de cosas.

      Un saludo