Loading Likes...

En estos últimos años el desarrollo Frontend ha entrado en un espiral de constante evolución.

Por tanto, aquellas épocas donde los desarrollos requerían pequeñas pinceladas de JavaScript para darle dinamismo a la Web han quedado en el pasado.

El desarrollo Frontend se ha vuelto tan complicado que se llega a hablar de tantos conceptos nuevos (Virtual DOM, Shadow DOM, Service Workers…) hasta el punto de invertir horas en la selección correcta de un patrón de diseño para la aplicación, de los cuales podríamos destacar dos:

En habitissimo, apostamos por la Arquitectura basadas en componentes.

¿Y qué es un Componente?

“Puedes pensar en Web Components como en widgets de interfaz de usuario reusables que son creados usando tecnología Web abierta” (MDN docs).

Los Web Components nos ofrecen un estándar que va enfocado a la creación de todo tipo de elementos  utilizables en una página web, tanto como para realizar interfaces de usuario como para presentar información.

¿Por qué y para qué?

Para ver el por qué y para qué vayamos un momento a la web de habitissimo y prestemos atención a la navegación.


Si tuviésemos que reutilizar esta misma navegación en diferentes vistas, podríamos tener varias soluciones:

  • Copiar el código en cada una de las diferentes vistas.
  • Separar el código en un archivo e importarlos en cada una de esas vistas.
  • Crear Web Components.
  1. Copiar código

Si copiamos el código de la navegación en varias vistas implica asumir un nuevo riesgo; ¿estamos seguros de que siempre vamos a modificar todas las navegaciones?

En un mundo perfecto en el que lo recordamos todo,  jamás nos vamos de vacaciones y dejamos a otro encargado de nuestro trabajo puede que sea posible. En un mundo imperfecto como el nuestro, es prácticamente imposible.

Por ello nos hallamos en una fuente de problemas al repetir código (programación de copiar y pegar) además de violar concepto de DRY

  1. Archivos separados.

Si bien es una solución válida a la hora de aplicar el concepto de DRY, vamos a imaginarnos un estado posible.

Nos hallamos trabajando en una aplicación donde dispone de apartado público (no requiere logueo) y otra privada (es necesario estar logueado).

Dependiendo de si el usuario está logueado o no mostraremos una navegación o otra, hay que resaltar que ambas navegaciones difieren en ciertos aspectos.

default_nav.php



<nav class="navbar navbar-default">
  <ul class="nav navbar-nav">
    <li><a href="#">Page 1</a></li>
    <li><a href="#">Page 2</a></li>
    <li><a href="#">Page 3</a></li>
  </ul>
</nav>

user_nav.php


 <nav class="navbar navbar-default">
   <ul class="nav navbar-nav">
     <li class="active"><a href="#">Home</a></li>
     <li class="dropdown">
       &lta class="dropdown-toggle" data-toggle="dropdown" href="#">
          <span class="caret"></span>
        </a>
       <ul>
         <li><a href="#">Page 1</a></li>
         <li><a href="#">Page 2</a></li>
         <li><a href="#">Page 3</a></li>
       </ul>
    </li>
    <li><a href="#">Page 4</a></li>
    <li><a href="#">Page 5</a></li>
  </ul>
</nav>

 Aquí surge la duda de siempre:

¿Es realmente necesario crear dos archivos o tener uno sólo con condicionales para mostrar o ocultar?

A medida que la aplicación vaya creciendo, nos enfrentaremos a situaciones donde será necesario introducir más y más condicionales, ¿y si mi aplicación ahora tiene varios tipos de usuarios? Usuarios con roles, usuario premium, plus, developer… al final nos hallaremos, tarde o temprano, ante una aplicación poco escalable.

 Volvamos al meollo, si analizamos un poco el código de las navegaciones puestas anteriormente, vemos que seguimos teniendo problemas en la aplicación, si bien son pequeñas, sigue siendo un problema y para entenderlo mejor crearemos una nueva situación:

 Pasa un tiempo desde el lanzamiento de nuestra aplicación al mercado, realizamos unas pruebas y vemos que añadiendo iconos a los links da una mejor experiencia de usuario.

Por ello la Product Owner solicita que el departamento técnico realice unos cambios: que los links tengan un icono para mejorar en UI/UX y ya que estamos mejorar la semántica de las clases CSS, ya no serán .nav-bar sino .navigation

 Todo estos cambios pasan a ser cambios sensibles: ¿Si realizo el cambio de nombre (.nav-bar) romperé otros sectores de la web? ¿Debo crear la clase .navigation y copiar todo para no romper nada? ¿Cómo sé yo que alguien no ha utilizado .navbar como un listado de items inline? ¿Me dejaré algún link o archivo sin modificar?.

Además somos incapaces de crear elementos reutilizables, pues tenemos un sistema poco extensible y mucho menos independiente.

 Web components al rescate.

  1. Web components.

 Realizaremos un refactor del código de la navegación de habitissimo dividiéndolo en componentes con el fin de crear un código reutilizable, adaptable a los cambios y sobre todo escalable.

Antes de empezar…

Es importante romper la interfaz de usuario en una jerarquía de componentes

Uno de mis consejos es que, si estáis trabajando con algún diseñador/a, vayáis a hablar con él/ella ya que es casi seguro que ellos/as ya hayan hecho esta jerarquía. Si no es el caso, dibuja pequeños cuadros alrededor del elemento y ponles un nombre 🙂

Ahora mismo podría surgirnos una duda: ¿Pero como sabemos que un elemento ha de ser un componente?

Tan sólo basta con aplicar el principio de responsabilidad única

Nota: He obviado algunos aspectos con el fin de obtener mayor brevedad.

  • Navbar: La agrupación (container) de todos las posibles elementos.
  • Logo: Componente Logo (logo de la empresa).
  • NavbarItem: especifican la apariencia del enlace correspondiente.
  • NavbarItemLink: representación del enlace.

 Con esto conseguimos que los componentes sean:

  • Reusables
  • Sin contexto específico: pueden operar en diferentes ambientes y contextos.
  • Extensibles: podemos extender un componente para crear un nuevo comportamiento.
  • Encapsulado: exponen interfaces que nos permiten usar su funcionalidad sin revelar detalles internos.
  • Independiente: diseñamos componentes que tengan dependencias mínimas de otros componentes, lo cual nos da la posibilidad de utilizarlos en diferentes ambientes sin afectar a otros componentes o sistemas.

En resumen, cada componente tiene su propia estructura, sus propios métodos y sus propias API.

 ¿Y cómo utilizamos los componentes dentro de una aplicación?

Basta con añadir los elementos custom creados


<Navbar>
  <Logo />
   <NavbarItem>
       <NavbarItemLink href="#">Page 1</NavbarItemLink>
       <NavbarItemLink href="#">Page 2</NavbarItemLink>
      <NavbarItemLink href="#">Page 3</NavbarItemLink>
   </NavbarItem>
</Navbar>

Conceptualmente todo es muy bonito, pero ¿cómo lo llevamos a código?

 Eso será en el siguiente capítulo.

Loading Likes...

Deja un comentario

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