El mapa mental completo y cómo recorrerlo

Ya sabes que hay tres modelos, qué resuelve cada uno y dónde se enchufan en el pipeline. Falta lo que convierte esa información en conocimiento operativo: un mapa mental que puedas evocar entero en cinco segundos y un orden de estudio que respete las dependencias reales entre conceptos. Esta lección cierra la ontología y deja el terreno preparado.

Las cuatro preguntas

Todo el mapa se comprime en cuatro preguntas encadenadas. Contestarlas en orden resuelve prácticamente cualquier decisión de arquitectura gráfica en la web, y contestarlas fuera de orden es la causa de la mayoría de las decisiones malas.

¿Esto tiene que existir como objeto después de dibujarlo? Si un elemento necesita identidad —hay que poder pulsarlo, nombrarlo, animarlo por separado, exportarlo— quiere modo retenido: SVG o DOM. Si solo tiene que aparecer, el modo inmediato sobra y basta el canvas.

¿Cuántos objetos cambian por fotograma? No cuántos hay: cuántos cambian. Decenas es territorio del DOM sin discusión. Cientos es la zona gris donde importa qué cambias. Miles es canvas.

¿El resultado tiene que sobrevivir al zoom, a la impresión o a un lector de pantalla? Esos tres requisitos son vectoriales y semánticos, y son la razón número uno para no usar canvas aunque el rendimiento lo permita.

¿El trabajo es por objeto o por píxel? Si es por píxel —filtros, mezclas, análisis de imagen, efectos— el canvas es la herramienta, y si el volumen crece, la GPU.

Cuatro preguntas, dos ejes: identidad frente a volumen, y objeto frente a píxel. Todo lo demás son detalles de implementación.

El orden en que se estudia el canvas

Los conceptos del canvas 2D tienen dependencias reales, y saltárselas produce la sensación de que la API es caprichosa cuando en realidad es bastante coherente. El orden que funciona es este.

Primero el modelo de imagen: qué es un raster, qué es un vector, y qué se gana y se pierde en cada uno. Sin eso, la mitad de los comportamientos del canvas parecen bugs.

Después el contexto y sus coordenadas, incluida la gestión de la resolución. Esta es la parte que más gente se salta y la que más problemas causa después, porque un canvas mal dimensionado hace que todo lo demás se vea mal y la culpa parezca estar en otro sitio.

Luego el modelo de rutas, que es el corazón de la API: la ruta actual, cómo se construye, cómo se pinta. Casi todos los métodos de dibujo son variaciones sobre ese modelo.

A continuación el estado del contexto: los estilos de trazo y relleno, la matriz de transformación, la pila de guardar y restaurar. Aquí está la clave de que el canvas sea manejable, porque pensar en espacios locales en lugar de en coordenadas absolutas es la diferencia entre código legible y trigonometría inmantenible.

Después las fuentes de píxeles: texto, imágenes y acceso directo al array. Los tres comparten la característica de traer datos de fuera del canvas, y los tres tienen trampas de rendimiento propias.

Luego la composición, que es el modelo de cómo se combina lo nuevo con lo que ya estaba, y sin la cual muchos efectos parecen magia.

Y por último las abstracciones y la producción: objetos de ruta reutilizables, dibujo fuera del hilo principal, interacción, animación y rendimiento.

Ese orden tiene una propiedad útil: cada bloque solo depende de los anteriores. Si algo no encaja, el hueco casi siempre está atrás, no delante.

Aplicar el mapa a un caso nuevo

La prueba de que el mapa funciona es usarlo antes de programar. Toma un requisito real: un panel que muestra la actividad de un servidor durante las últimas veinticuatro horas, con una banda por cada uno de los cuarenta servicios, resolución de un minuto, y la posibilidad de pasar el ratón para ver el detalle de una celda.

Primera pregunta: ¿los elementos necesitan identidad? Son cuarenta por mil cuatrocientos cuarenta, unas cincuenta y ocho mil celdas. Ninguna celda individual tiene identidad estable; lo que tiene identidad es la fila. Segunda pregunta: ¿cuántas cambian por fotograma? Ninguna, salvo al recargar datos o al hacer zoom. Tercera: ¿hace falta accesibilidad o impresión? La accesibilidad sí, pero a nivel de servicio, no de celda: un resumen textual por fila cubre el requisito. Cuarta: ¿el trabajo es por objeto o por píxel? Por píxel, básicamente, porque cada celda es un rectángulo de color derivado de un valor.

Conclusión sin escribir código: el mapa de calor va en canvas, las etiquetas de fila y la rejilla de ejes van en HTML posicionado al lado, el tooltip es un elemento del DOM que se coloca según las coordenadas calculadas, y la accesibilidad se resuelve con una tabla oculta o con un resumen por fila. El hit testing no necesita ni rutas ni canvas oculto: como la rejilla es regular, se calcula con dos divisiones. Y el redibujado solo ocurre al cambiar datos o zoom, así que no hay bucle de animación.

Ese razonamiento son tres minutos y ahorra semanas. La alternativa —empezar a escribir componentes y descubrir en el sprint tres que cincuenta y ocho mil nodos no van— es exactamente lo que el mapa existe para evitar.