Abrir las herramientas de desarrollo

Cómo se abren

Y una nota importante: en modo de desarrollo las herramientas suelen estar disponibles por omisión; en una compilación de publicación hay que activarlas explícitamente, y el nivel 10.4 explicó por qué conviene compilarlas y abrirlas bajo condición.

Las dos familias

Lo que cambia entre unas y otras, para no perder tiempo buscando:

• La inspección del árbol y de los estilos funciona igual en las dos, y es el noventa por ciento del uso.
• El perfilado de rendimiento es bastante más completo en las de Chromium. Si vas a analizar por qué algo va lento, hazlo en Windows.
• La consola y la depuración de JavaScript están en las dos, con interfaces distintas.
• Y la inspección de red es donde más se nota la diferencia — aunque en una aplicación que sigue el nivel 48.1 hay poca red en la webview que inspeccionar.

La estrategia práctica: depura la lógica donde te resulte cómodo y comprueba el aspecto en las tres. Nivel 53.3.

En la aplicación compilada

Aquí está el detalle que merece la pena y que casi nadie configura: poder abrir las herramientas en la versión que usan tus usuarios.

// compiladas siempre, abiertas solo bajo condición explícita#[cfg(feature = "devtools")]{    if std::env::var("MIAPP_DEVTOOLS").is_ok() || prefs::modo_diagnostico() {        window.open_devtools();    }}

Por qué merece la pena: cuando un usuario reporta un problema visual o de interfaz que no puedes reproducir, poder pedirle que active el modo de diagnóstico y te mande una captura de la consola convierte una incidencia sin salida en un diagnóstico de un minuto.

Y por qué no debe estar abierto por omisión: nivel 31.4. Compiladas sí, accesibles bajo condición, nunca abiertas solas.

Qué se puede inspeccionar y qué no

Una distinción que ahorra búsquedas frustrantes:

Y ahí está la trampa de depurar una aplicación de Tauri: la mitad de los problemas no se ven desde las herramientas del navegador, y la reacción instintiva es buscar más rato ahí en vez de mirar en el otro lado.