Navegar el árbol sin perderse
Teclado, breadcrumb, expansión recursiva y las tres formas de saltar entre la página y el nodo, para moverse por un DOM de diez mil nodos sin desorientarse.
Un árbol de DOM de una aplicación real tiene entre cinco y cincuenta mil nodos, con anidamientos de veinte niveles que producen sangrados de doscientos píxeles y wrappers de framework que no significan nada. Navegar eso a base de triángulos de expansión es un ejercicio de paciencia. Hay media docena de mecanismos pensados exactamente para eso, y cuatro de ellos son de teclado.
- Recorrer, expandir y colapsar el árbol completo con el teclado.
- Usar el breadcrumb para entender la posición del nodo seleccionado en la jerarquía.
- Saltar en ambas direcciones entre un punto de la página y su nodo, y viceversa.
- Trasladar un nodo del panel a la consola para operar sobre él programáticamente.
Moverse por el árbol
El teclado dentro del árbol
Con un nodo seleccionado, las flechas hacen lo que esperarías de un árbol: arriba y abajo recorren los nodos visibles en orden de documento, derecha expande el nodo o baja al primer hijo si ya estaba expandido, e izquierda colapsa o sube al padre.
Lo que cambia la experiencia son dos modificadores.
Expansión recursiva. Pulsar la flecha derecha con la tecla de opción o de alt mantenida expande el nodo y todos sus descendientes de golpe. Sobre un subárbol de trescientos nodos es la diferencia entre treinta clics y uno. El mismo modificador con la flecha izquierda colapsa todo el subárbol.
Editar sin ratón. Con un nodo seleccionado, la tecla de entrada empieza a editar el primer atributo, y el tabulador va saltando entre atributos y valores. Se puede recorrer y modificar toda la lista de atributos de un elemento sin tocar el ratón, lo que en formularios con muchos data- acelera bastante.
Además, las teclas de inicio y fin saltan al principio y al final del árbol visible, y escribir una letra con el foco en el árbol salta al siguiente nodo cuyo nombre de etiqueta empiece por esa letra, que es una forma sorprendentemente rápida de encontrar la única table de una sección.
El breadcrumb
Bajo el árbol hay una tira horizontal que muestra la cadena de ancestros del nodo seleccionado, desde html hasta él. Hace tres cosas y las tres son útiles.
Da contexto de profundidad de un vistazo: si el nodo que crees haber seleccionado está a diecinueve niveles y esperabas tres, algo no cuadra.
Permite saltar a cualquier ancestro con un clic, sin colapsar nada ni perder la posición. Es la forma más rápida de subir seis niveles.
Y al pasar el cursor sobre cada segmento, resalta ese ancestro en la página, lo que responde visualmente a la pregunta de qué caja es cada wrapper. En una aplicación con seis divs anidados sin ninguna semántica, recorrer el breadcrumb con el ratón enseña en cinco segundos cuál de los seis es el que tiene el tamaño que te molesta.
Cuando la cadena es más larga que el ancho disponible, el breadcrumb se recorta con un indicador y se puede desplazar.
Ir de la página al nodo y del nodo a la página
Son dos operaciones distintas y hay tres caminos para cada dirección.
De la página al nodo. El modo de inspección, con Cmd+Shift+C o Ctrl+Shift+C, resalta el elemento bajo el cursor mostrando una etiqueta con su selector, sus dimensiones, su color y su fuente, y al pulsar lo selecciona en el árbol. El clic derecho con la opción de inspeccionar hace lo mismo en un paso. Y desde la consola, inspect(elemento) salta al panel con ese nodo seleccionado, que es la vía cuando has encontrado el elemento programáticamente.
Del nodo a la página. Pasar el cursor por un nodo del árbol lo resalta en pantalla, con el modelo de caja dibujado en colores por capa. Si el nodo está fuera del área visible, la opción de desplazarlo a la vista del menú contextual lo trae. Y si quieres ver la caja sin que el resaltado desaparezca al mover el ratón, la captura de pantalla del nodo del menú contextual te da una imagen exacta de su caja.
El resaltado del inspector muestra en la etiqueta flotante el nombre de la fuente aplicada y el contraste del texto respecto a su fondo. Son dos datos que la gente busca en otros sitios y que están ahí, en el hover, antes de haber hecho ningún clic.
Llevarse un nodo a la consola
El puente entre el panel y la consola es donde el árbol pasa de ser un visor a ser un espacio de trabajo. Hay tres mecanismos.
La variable $0. Siempre apunta al nodo seleccionado en Elements. Es la utilidad más usada de las DevTools con diferencia, y con ella el patrón de trabajo es: selecciono un nodo con el ratón, salto a la consola con Esc, y opero. Las variables $1 a $4 guardan las cuatro selecciones anteriores, lo que permite comparar dos nodos.
// Comparar el estilo computado de dos nodos seleccionados consecutivamente
const a = getComputedStyle($1), b = getComputedStyle($0);
const distintos = [...a].filter(p => a.getPropertyValue(p) !== b.getPropertyValue(p));
console.table(distintos.map(p => ({ propiedad: p, uno: a.getPropertyValue(p), dos: b.getPropertyValue(p) })));
Ese fragmento resuelve de un golpe la pregunta “estos dos elementos parecen iguales, ¿por qué uno se ve distinto?”, que en modo manual son veinte minutos de comparar paneles.
Guardar como variable global. La opción del menú contextual crea una variable temp1, temp2 y sucesivas que apuntan al nodo. A diferencia de $0, no cambia cuando seleccionas otra cosa, así que es lo correcto cuando vas a trabajar un rato con ese nodo concreto.
Copiar la referencia en el sentido inverso, con inspect(), cierra el círculo: encuentras el nodo con una consulta compleja en la consola y lo mandas al panel para verlo en su contexto.
Todo lo anterior asume implícitamente algo que en una aplicación con framework es falso: que el nodo que seleccionaste sigue siendo el mismo nodo un segundo después. No lo es. Cuando un componente se vuelve a renderizar, el reconciliador puede sustituir el nodo del DOM por otro nuevo con el mismo aspecto, y en ese momento tu selección se pierde o —peor— $0 sigue apuntando a un nodo huérfano que ya no está en el documento y que por tanto no reacciona a nada de lo que le hagas. El síntoma es inconfundible y desquiciante: cambias un estilo en el panel y no pasa nada; lo cambias otra vez y sigue sin pasar nada; empiezas a dudar de la especificidad cuando lo que ocurre es que estás editando un nodo que ya no está en pantalla. La comprobación cuesta un segundo y hay que interiorizarla: escribe $0.isConnected en la consola. Si devuelve false, tu nodo está desconectado del documento y todo lo que hagas con él es invisible. La misma comprobación explica el fenómeno inverso, que es una de las causas clásicas de fuga de memoria: un nodo desconectado que sigue vivo porque algo mantiene una referencia a él, exactamente como acaba de hacer tu consola. De ahí que las trazas que loguean nodos del DOM sean tan malas para la memoria, y de ahí que en una aplicación reactiva convenga trabajar con selectores estables en vez de con referencias guardadas.
Reducir el ruido del árbol
Dos ajustes ayudan cuando el árbol es inmanejable. El primero es el ajuste de saltos de línea en los atributos: por defecto un nodo con quince clases de utilidad ocupa cuatro líneas y hace ilegible la estructura; forzando una sola línea el árbol vuelve a leerse como un árbol, a costa de no ver los atributos completos.
El segundo es ocultar los distintivos que no uses. En una página con muchos contenedores de scroll, las etiquetas de distintivo pueden ocupar más espacio horizontal que el propio marcado.
Y hay una tercera técnica que no es un ajuste: colapsar todo y bajar por el breadcrumb. Cuando te has perdido en un árbol enorme, colapsar el nodo raíz y volver a bajar desde arriba usando el resaltado al pasar el cursor reconstruye el mapa mental en menos tiempo que intentar orientarte donde estabas.