Herramientas: DevTools, profiler y el grafo de dependencias

Un depurador con método y sin herramientas es lento; un depurador con herramientas y sin método es peligroso, porque las herramientas producen números con enorme autoridad y esos números responden preguntas que quizá no son la tuya. Esta lección entrega el instrumental que acelera el árbol de diagnóstico, pero antes de cada aparato explica qué mide exactamente y qué no mide, que es la parte que casi nadie se molesta en aprender y la que separa una sesión de depuración de una colección de capturas de pantalla. Verás que el profiler de React no responde a la pregunta que su nombre popular sugiere, que las DevTools de Redux no son un visor de estado sino un registro de intenciones, y que en los sistemas de grano fino el objeto de estudio deja de ser el render y pasa a ser el grafo, con lo que casi todo el instrumental anterior queda sin objeto. Y verás, al final, lo más importante: cómo fabricar tu propio instrumento en veinte líneas cuando el ecosistema no te da ninguno, porque el grafo de dependencias siempre se puede reconstruir instrumentando sus dos únicas operaciones.

El profiler: qué mide de verdad y cómo leer su columna de causas

El profiler de React graba una sesión de renders y devuelve, por cada confirmación, qué componentes se ejecutaron, cuánto tardó cada uno y qué lo desencadenó. Esa última columna es la valiosa y la que casi nadie explota: para cada componente reporta si se renderizó porque cambió su estado propio, porque cambió un contexto que consume, porque cambió una prop concreta —y la nombra— o simplemente porque su padre se renderizó. Esa lista es la respuesta directa al nodo de la dependencia sobrante de la lección anterior, obtenida sin escribir una línea de instrumentación.

Hay una segunda lectura del profiler que muy poca gente usa y que resulta más informativa que la primera: el gráfico de llamas comparado entre dos confirmaciones consecutivas. No mires la forma absoluta de cada una, mira qué ramas aparecen en ambas. Una rama que se repite idéntica en confirmaciones sucesivas es trabajo que se está rehaciendo sin que su entrada haya cambiado, y esa es la definición operativa de una arista sobrante. La forma del gráfico también diagnostica por sí sola: una franja ancha y plana señala un padre que arrastra a decenas de hijos y apunta a una prop inestable en el nivel superior, mientras que una columna estrecha y profunda señala una cadena de dependencias encadenadas y apunta a una cascada.

Lo que el profiler no puede decirte es si el trabajo era necesario. Mide coste, no legitimidad. Un componente que tarda doce milisegundos puede estar perfectamente justificado y otro que tarda medio milisegundo puede ser puro desperdicio repetido doscientas veces. Por eso la lectura correcta nunca empieza por el componente más lento: empieza por el patrón de repetición. Busca el componente que aparece en más confirmaciones consecutivas con la misma causa declarada, porque ahí es donde una arista sobrante se está cobrando su renta en cada interacción.

El registro de acciones: una historia auditable, no un visor de estado

Las DevTools de Redux se describen mal cuando se presentan como una manera de ver el estado. Ver el estado lo hace cualquier traza. Lo que aportan es otra cosa: una historia ordenada de intenciones con nombre, donde cada entrada declara qué se quiso hacer y qué diferencia produjo eso en el árbol de estado. Esa diferencia, mostrada campo a campo, es lo que convierte una pregunta difusa en una pregunta contestada, porque el fallo de estado casi siempre se ve como una acción que no aparece cuando debería, una que aparece dos veces, o una cuya diferencia no es la que su nombre prometía.

El viaje en el tiempo —retroceder a un estado anterior y volver a avanzar— parece magia y no lo es: funciona porque las transiciones son funciones puras del estado previo y la acción, de modo que reproducir el registro desde el principio reconstruye cualquier punto intermedio con exactitud. De ahí se sigue una consecuencia práctica que conviene tener presente antes de confiar en la herramienta: si tus reducers leen la hora, generan identificadores aleatorios o llaman a la red, el viaje en el tiempo miente. No es un defecto de las DevTools; es que has roto la premisa que las hacía posibles.

// Instrumentacion equivalente para un store que no tenga DevTools propias.
function conRegistro<T>(crear: StateCreator<T>): StateCreator<T> {
  return (set, get, api) =>
    crear((parcial, reemplazar, nombre) => {
      const antes = get()
      set(parcial, reemplazar)
      console.groupCollapsed('accion', nombre ?? 'anonima')
      console.log('antes', antes, 'despues', get())
      console.trace('origen de la escritura')
      console.groupEnd()
    }, get, api)
}

La traza de origen incluida ahí resuelve el caso que más tiempo consume en aplicaciones grandes: la escritura correcta que nadie sabe quién disparó. Con la pila de llamadas capturada en el momento de escribir, la pregunta se responde en un vistazo en lugar de mediante una búsqueda a ciegas por todo el repositorio.

Conviene además explotar una capacidad del registro que casi nadie usa y que convierte una sesión de depuración en un artefacto compartible: la exportación de la secuencia completa de acciones. Un registro exportado es una reproducción determinista del fallo que otro compañero puede importar en su propia máquina para llegar exactamente al mismo estado, sin necesidad de reproducir tu sesión, tus datos ni tu cuenta. Es el equivalente de estado del volcado de memoria en un lenguaje de sistemas, y es la razón por la que merece la pena mantener las acciones con nombres descriptivos: un registro cuyas entradas se llaman actualizar o establecer no reproduce ninguna intención y no sirve de informe para nadie.

Grano fino: el objeto de estudio deja de ser el render

En Solid, en Vue con signals o en cualquier sistema de grano fino, casi todo el instrumental anterior pierde sentido, y no porque sea peor sino porque el fenómeno que medía ha desaparecido. El cuerpo del componente se ejecuta una única vez, así que contar renders no informa de nada. Lo que existe es un grafo persistente de fuentes, derivaciones y efectos, y la depuración consiste en recorrerlo preguntando por las aristas de cada nodo: quién me lee y a quién leo.

// Instrumentar un nodo concreto para ver cuando se recalcula y por que.
const totalTrazado = createMemo(() => {
  const valor = lineas().reduce((s, l) => s + l.precio, 0)
  console.log('recalculo del total', valor, 'lineas:', lineas().length)
  return valor
})

// Ver la propagacion completa de una escritura: cuantos efectos despierta.
batch(() => {
  console.time('propagacion')
  setLineas([...lineas(), nueva])
  console.timeEnd('propagacion')
})

Este cambio de objeto de estudio tiene una consecuencia que sorprende a quien llega desde React: en grano fino, el bug de rendimiento típico deja de ser el trabajo repetido y pasa a ser el trabajo mal ubicado. Como el sistema recalcula únicamente los nodos afectados, casi nunca sobra ejecución; lo que sobra es una derivación colocada demasiado arriba en el grafo, de modo que un cambio pequeño obliga a recomponer una estructura grande. La instrumentación correcta, por tanto, no cuenta ejecuciones sino que mide cuánto trabajo hace cada recálculo, y la corrección no consiste en memoizar sino en partir la derivación en varias más pequeñas y más cercanas a sus fuentes.

La pregunta que sustituye a por qué se renderizó es por qué se recalculó este nodo, y se responde imprimiendo dentro de la derivación sospechosa las fuentes que lee. Si una derivación se recalcula cuando ninguna de sus fuentes cambió de valor, tienes una arista sobrante exactamente igual que en la lección anterior; si no se recalcula cuando una sí cambió, tienes la suscripción ausente de la lección primera. El árbol de diagnóstico es el mismo, cambia el aparato con el que se responde cada nodo.

flowchart LR
S[que sistema tengo delante] --> R[reejecuta el componente]
S --> G[grano fino con grafo persistente]
R --> P[profiler: causa por render y frecuencia]
R --> L[registro de acciones: intencion y diferencia]
G --> N[trazar el nodo: fuentes leidas y recalculos]
P --> D[misma pregunta del arbol de diagnostico]
L --> D
N --> D
style S fill:#cba6f7,color:#11111b
style D fill:#a6e3a1,color:#11111b
style R fill:#89b4fa,color:#11111b
style G fill:#f9e2af,color:#11111b

Sin herramienta: reconstruir el grafo a mano

Hay un cuarto instrumento que no es una extensión y que resuelve la clase de fallos que ninguna de las anteriores alcanza: la marca temporal. Cuando el problema no es cuánto trabajo se hace sino en qué orden ocurren las cosas —una escritura que llega antes de que su suscriptor exista, dos actualizaciones que se pisan, un efecto que corre antes de que el estado se haya asentado—, lo que necesitas es una línea de tiempo, no un recuento. Sembrar marcas en los puntos críticos y leerlas en la pista de rendimiento del navegador convierte una sospecha de carrera en una secuencia observable, y es el único modo honesto de depurar el orden en un sistema donde la propagación es asíncrona.

Habrá casos en los que no exista extensión, el entorno sea de producción o el estado viva en una librería sin instrumentación. No importa: cualquier grafo reactivo se define por dos operaciones, el registro de una lectura y la notificación de una escritura, y envolver ambas basta para reconstruirlo entero. Es el mismo par de operaciones gemelas que localizaba el núcleo de cualquier librería, usado ahora para observarlo desde fuera.

// Envolver la fuente para registrar cada lectura y cada escritura con su origen.
function trazar<T extends object>(fuente: T, nombre: string): T {
  return new Proxy(fuente, {
    get(obj, clave) {
      console.debug('lectura', nombre, String(clave))
      return Reflect.get(obj, clave)
    },
    set(obj, clave, valor) {
      console.debug('escritura', nombre, String(clave), valor, new Error().stack)
      return Reflect.set(obj, clave, valor)
    },
  })
}

Con esa envoltura activa durante una interacción tienes el material bruto para el grafo: cada lectura te dice quién depende de qué y cada escritura te dice quién dispara qué, con la pila que lo originó. Agrupar esas trazas por clave produce, en un minuto, un mapa de aristas que ninguna extensión te habría dado con más precisión. Es tosco, es ruidoso y funciona en cualquier framework de cualquier año.