CAPÍTULO 4 · Una interfaz que el equipo pueda mantener
Una pantalla tiene estados, aunque no los hayamos nombrado
El template muestra la estructura inicial, pero el usuario no permanece quieto frente a ella. Busca, cambia un filtro y espera resultados. Durante ese tiempo la pantalla puede estar cargando, mostrar datos o tener un error. Si esos estados aparecen como cambios dispersos en varios eventos, termina siendo difícil saber por qué un botón quedó deshabilitado o qué respuesta está viendo la persona.
Organizamos el frontend por responsabilidades y hacemos explícito su estado. Cada módulo conoce qué interacción atiende y cómo presenta su resultado. La idea de segregación vuelve a aparecer con otro lenguaje: no se trata de dividir archivos por tamaño, sino de poder seguir el comportamiento sin recorrer todo el proyecto.
Con esa organización una pantalla se entiende mejor por dentro. Pero todavía puede resolver cada llamada HTTP a su manera. Antes de agregar más tablas y formularios conviene acordar cómo se enviarán las solicitudes y qué hará la interfaz cuando el servidor no responda como esperaba.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Un panel con estado visible
Las flechas muestran transiciones del modelo. Los eventos y guardas determinan cuáles están permitidas.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Interacción. Usuario ejecuta acción
- Estado. Representa situación actual
- Módulo. Aplica transición explícita
- Render. Actualiza interfaz desde estado
01 / EL PROBLEMA
¿Para qué sirve?
Cuando eventos, fetch y manipulación del DOM viven mezclados, una actualización puede dejar datos y pantalla inconsistentes.
02 / COMPRENDER
El concepto, explicado
Un módulo api habla con el servidor. state conserva el estado actual. view dibuja. controller coordina eventos y secuencia. Esta separación puede hacerse con JavaScript nativo.
El estado debe tener una fuente reconocible. Si una tabla y una tarjeta conservan dos copias de un mismo sensor, necesitas definir cómo se sincronizan.
03 / CONSTRUIR
Implementación paso a paso
- Crea módulos api, state y view.
- Centraliza el estado seleccionado.
- Usa textContent para texto externo.
- Limpia listeners al desmontar componentes.
04 / APLICAR
Ejemplo en SensorHub
// sensors.state.js
export const state = { selected: null, sensors: [] };
// sensors.view.js
export function renderSelected(sensor, element) {
element.textContent = sensor ? sensor.code : "Selecciona un sensor";
}
// sensors.controller.js
import { state } from "./sensors.state.js";
import { renderSelected } from "./sensors.view.js";
export function selectSensor(sensor) {
state.selected = sensor;
renderSelected(sensor, document.querySelector("#selected-sensor"));
}Cómo leer el ejemplo
- Cada módulo tiene un contrato pequeño.
- Usa script type="module" al cargar imports en el navegador.
- textContent no interpreta el código del sensor como HTML.
Error habitual
Agregar listeners en cada render sin limpiar los anteriores puede ejecutar la misma acción varias veces.
05 / PRACTICAR
Tu turno
Haz que cambiar de sensor limpie el gráfico anterior.
Ver solución orientativa
El controlador actualiza selected, cancela la suscripción previa y pide a view reiniciar la serie antes de cargar el nuevo histórico.
06 / VERIFICAR
Cómo sabes que funciona
- Cambiar selección no conserva puntos de otro sensor.
- Cada clic produce una sola operación.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Cliente API compartido y errores →Continuar en modo relato