Estado de la aplicación — JS: Arquitectura Front-end

Manipular el DOM es sencillo solo en las situaciones más básicas. Pero en cuanto necesitas crear una aplicación completa, aunque sea pequeña, el código se vuelve un caos. Unos pocos manejadores de eventos son suficientes para perderse, y con cada nuevo evento, la complejidad del código crece aún más. En aplicaciones reales, hay cientos de eventos. ¿Por qué pasa esto?

Aunque este problema no es exclusivo del frontend, es aquí donde se vuelve más crítico. La arquitectura basada en eventos y el DOM, sin una buena organización, generan código confuso de inmediato. Es evidente que se necesita una buena arquitectura, pero ¿dónde y cómo implementarla?

Vamos a abordar la arquitectura correcta desde la perspectiva del backend. Como ya sabes o imaginas, las aplicaciones backend consisten al menos en dos partes: la base de datos y el código. Los formularios enviados al servidor cambian el estado de la aplicación (es decir, sus datos), que se almacenan en la base de datos, y a partir de este estado se genera una respuesta en forma de página HTML.

En los proyectos web típicos, las aplicaciones suelen hacer dos cosas: actualizar datos en la base de datos o extraer esos datos para generar HTML. La necesidad de una base de datos es algo obvio y claro para todos, pero no tanto en el frontend. El DOM permite almacenar el estado dentro de sí mismo y, además, tiende a fomentar esta práctica. A lo largo del curso, veremos varias veces situaciones donde necesitamos realizar una acción que dependa de lo que está en pantalla, lo que nos obliga a interactuar con el DOM para trabajar con esos datos.

See the Pen js_dom_state_in_dom by Códica (@hexlet) on CodePen.

El principal problema de este enfoque es la falta de una única fuente de verdad. Los mismos datos pueden usarse varias veces en una misma página, y a veces de manera diferente. Imagina una situación en la que necesitas mostrar la cantidad de artículos en la página. Para contarlos, tendrías que escribir un código como este:

// Cada artículo está marcado con la clase .article
const articles = document.querySelectorAll('.article');
articles.length; // cantidad de artículos

Si algunos de nuestros artículos se muestran en un bloque y otros en otro, tendremos que acceder a cada bloque para reunir todos los artículos. Cuanto más complejamos el diseño, más complicado será trabajar con estos datos: agregarlos, actualizarlos y usarlos. Al mirar el código, no será fácil entender de dónde provienen los datos. Además, estarán fuertemente ligados a la estructura específica del marcado.

Separar el estado de la aplicación

Para construir una arquitectura adecuada, el primer paso es separar los datos con los que opera la aplicación del DOM. Estos datos deben ser almacenados en una variable separada a nivel de la aplicación (no globalmente). Esto permite separar la manipulación de los datos de su representación en el DOM.

Con esta organización, el flujo de trabajo se ve así:

• Se produce un evento.
• El manejador de eventos modifica el estado de los datos.
• El DOM se actualiza en función de los nuevos datos.

A continuación, se muestra la implementación de esta idea con un ejemplo simple de un contador. En este caso, el estado consiste en un único número. Al hacer clic en el botón más (+), el número aumenta en uno; al hacer clic en el botón menos (-), el número disminuye en uno.

See the Pen js_dom_state_simple by Códica (@hexlet) on CodePen.

Aquí no hay manipulación del DOM para extraer el valor actual; este se almacena en una variable y está disponible para todos los manejadores. Este enfoque no solo simplifica el almacenamiento y manejo de datos, sino también la depuración. En cualquier momento se puede inspeccionar el estado interno y compararlo con lo que se muestra en pantalla. De hecho, la apariencia de la página refleja el estado actual de la aplicación en la pantalla.