web design

Nuestra web, nuestros componentes

Hoy en día seguimos discutiendo la ganancia de generar nuestra propia librería de componentes de UI. Sin embargo, son estas las abstracciones que hacen que ciertos aspectos cobren el protagonismo que merecen; como por ejemplo: la accesibilidad de nuestras aplicaciones.

Gisela

Oct 26, 2020 • 5 min read

> y por qué un día me convencí de dejar de abrir un “inocente div” para mi componente de front.

Hoy en día, afortunadamente, ya no es una discusión la necesidad de desarrollar un proyecto contando con un repositorio de código, un CI o un esquema de releases automatizados. Pero me pregunto: ¿por qué no pasa lo mismo con los componentes de mis aplicaciones? ¿Cómo es posible que estemos discutiendo la ganancia de generar nuestra propia librería de componentes de UI?

Incluso, muchas veces, he escuchado que es una decisión que limita el desarrollo. Argumento con el que estoy personalmente en contra: son estas las abstracciones que nos ayudan a potenciar el desarrollo, haciendo que ciertos aspectos, que tendemos a dejar relegados, cobren el protagonismo que merecen; como por ejemplo: la accesibilidad de nuestras aplicaciones.

Qué debería incluir toda librería de componentes: Tanto elementos HTML básicos como componentes propios de nuestra aplicación.

Elementos HTML básicos

Estamos hablando de los h1, h2, a, button, div, img, section. ¿Y por qué debería crear mi propia librería de componentes para TODO elemento HTML? ¿Qué responsabilidad le doy a mi wrapper?

Rápidamente puedo pensar en dos responsabilidades:

Asegurar el HTML semántico
Usar de forma apropiada los tags ARIA
Facilitar el control de cambios de forma consistente

Asegurar el HTML semántico

Veamos este ejemplo:

<html>
<style>
  body { font-family: "Gill Sans Extrabold", Helvetica, sans-serif }
  h1, .h1{
  color:violet;
  font-size: 2em;
  font-weight: bold;
}
</style>
<body>
  <h1>Soy un titulo</h1>
  <div class="h1">Yo quisiera</div>
</body>
</html>

Aquí simplemente pueden "verse" iguales, pero en la práctica no lo son, dado que:

Tanto las herramientas que contribuyen con la accesibilidad, desde un screen reader hasta un plugin que interpreta el contenido y adapta contrastes o jerarquías de textos, como las personas que trabajan programando, esperan encontrarse con los elementos conocidos y nosotros deliberadamente no los estamos usando: siempre hay que usar los elementos HTML con la semántica que fueron pensados.
Vamos a tener penalizaciones, por ejemplo en SEO de nuestra página, dado que muchos bots que indexan sites y generan el posicionamiento de resultados buscan ciertos tags (además del div para generar resultados!)

Usar de forma apropiada los tags ARIA

ARIA significa Accessible Rich Internet Applications. Les dejo este link https://developer.mozilla.org/es/docs/Web/Accessibility/ARIA que explica de forma clara la idea detraś de ello.

Supongamos que por algún motivo nuestra aplicación necesita un componente que represente un título de nivel 7: un "h7" que no viene en el estándar ¿Cuál es la implementación mínima? En ese caso deberíamos de implementarlo como:

<div role="heading" aria-level="7">Titulo 7</div>

Sí, son sólo 2 elementos a agregar al div. Suelen ser de los que, sin darnos cuenta, nos olvidamos y entonces todas esas maravillosas herramientas que contribuyen con la inclusión ya no pueden hacer demasiado.

Es muy probable que hayas usado alguna vez el tag <img> para renderizar una imagen ¿Sabías que los browser en caso de error al renderizar la imagen muestran el texto que escribimos como alt? ¿Sabían que los lectores de pantalla si no se definen el alt lee el path a la imagen? Desde este punto de vista nunca deberíamos agregar una imagen sin su texto alternativo.

Si lo incluimos en nuestra librería podemos obligar a indicar siempre un texto alternativo o podríamos generar convenciones para que esto sea automático. Por ejemplo, en caso de no indicarlo explícitamente incluir la última parte del path de la imagen: lejos está del ideal pero peor sería que nuestra descripción default sea un path y la imagen quede sin cargar con una cruz roja indicando el error (en el mejor de los casos).

En este link: https://w3c.github.io/using-aria/ pueden encontrar una guía que nos ayuda a usar los tags en nuestra página HTML de forma correcta.

Facilitar el control de cambios de forma consistente

Si leemos las razones anteriores podríamos decir que son argumentos para usar los tags html de forma completa y respetando los estándares: Cosas que podemos hacer sin necesidad de crear ningún componente que wrapee a uno tradicional. O en código, les di motivos para que en nuestro html escribamos:

<div role="heading" aria-level="7" class="H7">Titulo 7</div>

<img src="https://www.10pines.com/packs/media/images/10pines-team-all-f8ff0cd1.jpg" alt="Equipo 10Pines" />

Pero no termina de quedar claro qué ganamos escribiendo

<H7>Titulo 7</H7>

<Img src="https://www.10pines.com/packs/media/images/10pines-team-all-f8ff0cd1.jpg" alt="Equipo 10Pines" />

A eso va este motivo, al generar esta abstracción gano: control, consistencia y completitud.

Dado que al usar este componente propio en toda mi aplicación hay un único lugar donde se define como se va a traducir a html base y puedo garantizar que mi aplicación siempre va a renderizar los mismos componentes con las mismas propiedades.

Asimismo, si me olvidé de algo importante que tiene que estar presente en todos los elementos, lo modifico en un solo lado y se refleja en toda la aplicación de forma inmediata.

Componentes propios

Si usamos tecnologías actuales para el desarrollo web, como por ejemplo React, Vue o Angular (en sus últimas versiones), entonces será muy sencillo definir nuestros propios componentes que se encarguen de la presentación únicamente.

Nuevamente mis justificaciones favoritas para construir componentes propios (usando los tags HTML ya wrapeados) tienen que ver con consistencia y control. En particular:

Consistencia de:
- Estilos: por ejemplo, puedo asegurar que todas mis secciones se van a delimitar de la misma forma, todos mis dropdowns van a tener el mismo ícono para expandir y contraer las opciones. Vamos a respetar el mismo espaciado y vamos a usar la paleta de colores que nuestro producto decide usar, entre otras cosas.
- Interacciones permitidas: puedo asegurar que el feedback al usuario es consistente para el mismo componente. Por ejemplo, un botón: mismo feedback al hacer click, over, mantener presionado, seleccionarlo con un tab, etc. Todos mis botones desactivados se van a comportar de la misma forma.
- Animaciones: sencillamente vamos a respetarlas a lo largo de la aplicación, por ejemplo, ahora todas mis secciones colapsables van a expandirse a la misma velocidad y renderizar su contenido de la misma forma en vez de sencillamente aparecer y desaparecer. Y si quiero modificarlo me aseguro de modificar todas a la vez.

Variantes controladas por componente en cuanto a tamaños, estados: es decir, es mucho más sencillo que sigamos un mismo estilo en toda la app.

Podemos englobar estas menciones particulares aplicadas a la web justamente con la idea de DRY: don’t repeat yourself, que tanto nos gusta mencionar.

En particular para la UI nos interesa conservar esta consistencia porque brinda una mejor experiencia de usuario para nuestro producto.

En resumen, puedo decir que por esta decisión, los componentes de mi web son más sencillos de adaptar y si me olvidé de algo lo cambiamos de forma centralizada, con lo cual brindamos una experiencia consistente y aseguramos que se mantiene el estilo de nuestro producto.

Resumime que quedó largo

El desarrollo frontend, y en especial el desarrollo web en particular, involucra muchos aspectos a tener en cuenta en todo momento: uno de ellos es la experiencia de usuario, que también se relaciona con la accesibilidad de nuestras aplicaciones.

Usando las herramientas actuales es muy sencillo generar nuestros propios componentes que tengan como responsabilidad velar por varios de estos aspectos en forma consistente y controlada.

Deberíamos impulsar que en nuestros productos generemos nuestros propios wrappers de componentes básicos HTML y construyamos sobre ellos nuestros propios componentes reutilizables de mayor nivel. De esta forma aseguramos consistencia y simplificamos el camino por, entre otras, una web más accesible.