Un buen profesional es aquél que conoce bien las herramientas de que dispone. Una de las principales herramientas que los desarrolladores de WordPress tenemos a nuestro alcance es la consola de desarrollo JavaScript que ofrece nuestro navegador. En esta entrada veremos todo lo que necesitas saber sobre la consola de desarrollador del navegador, junto a algunos trucos y curiosidades que, quizás, no conocías.
Cómo activar la consola de desarrollador
Aunque imagino que sabes de sobra como hacerlo, no está de más recordar a los más despistados cómo pueden acceder a la consola JavaScript de su navegador. Si eres usuario de Firefox, basta con que hagas clic en el menú (esquina superior derecha) y busques la opción Web Developer, tal y como puedes ver a continuación:
Luego, selecciona Web Console:
y aparecerá la consola en tu navegador, tal y como puedes ver en la siguiente captura de pantalla. Recuerda que es posible configurar dónde quieres que aparezca exactamente el panel, ya sea en una esquina de la ventana del navegador o como una ventana aparte.
Si, por otro lado, eres usuario de Chrome, el procedimiento es muy parecido: simplemente accede al menú, selecciona More Tools y, luego, Developer Tools:
Cómo usar la consola de desarrollador
La consola JavaScript de nuestro navegador sirve para ver los logs que lanzamos en nuestros scripts y como intérprete JavaScript desde el que lanzar pequeños comandos y ver sus efectos en la web.
Como desarrollador de plugins para WordPress, la principal utilidad que tiene para mí la consola es debugar mi código, así que veamos qué herramientas nos ofrece para ello.
#1 Diferentes niveles de log
El primer motivo por el cual un desarrollador suele abrir la consola JavaScript es para debugar su código. Cuando se produce un error o algo está fallando, lo más habitual es que aparezca dicho error en la consola. Y, si quieres, tú mismo puedes lanzar tus propios mensajes informativos, avisos o errores cuando te plazca.
En la captura anterior, por ejemplo, vemos que el objeto console (objeto global cuyo objetivo es ayudarnos con el debugging) dispone de diferentes métodos para escribir mensajes en la consola:
debugylogmuestran mensajes sin ninguna floritura.infomuestra mensajes de información. En Firefox van acompañados de un icono informativo.warnmuestra avisos, normalmente señalando algún problema o algo que no está del todo bien. Suele aparecer resaltado en amarillo y con un icono de aviso.errorse suele reservar para los errores más graves (esto es, cosas que realmente han fallado). Se muestra en rojo y da acceso a la pila de ejecución (es decir, qué función generó el error y tal).
La ventaja de usar diferentes niveles de log es que podemos escoger en todo momento qué mensajes queremos que se muestren. Por ejemplo, en la siguiente captura hemos desactivado los mensajes de tipo Info y Debug, tal y como puedes ver en la segunda fila de herramientas, en el centro de la imagen:
#2 Controlando el tiempo de ejecución
Hay un mantra bastante conocido en el desarrollo agile que es «primero haz que funcione, luego hazlo bien y luego hazlo rápido». Cuando acabamos de picar código y lo probamos con datos reales, no es nada raro que el código sea excesivamente lento e ineficiente. Es entonces cuando debemos buscar qué parte del código es la que está tardando tanto y corregirla.
Aunque existen herramientas como los profilers para encontrar los culpables y entender exactamente qué está devorando los recursos, muchas veces nos basta con saber qué función es la que más tarda. Para ello, un pequeño contador de tiempo es lo más útil.
Si quieres saber cuánto tarda un trozo de código en concreto en ejecutarse, pon en marcha un cronómetro al principio del código (console.time) y detenlo (console.timeEnd) cuando tu código acabe:
console.time( 'Timer' );
// código que queremos controlar
console.timeEnd( 'Timer' );Cuando el código llega al timeEnd, se escribirá en la consola el tiempo total que el cronómetro ha estado funcionando:
Timer: 655ms - timer endedFíjate que cuando iniciamos y detenemos un cronómetro le damos un nombre (en mi ejemplo, «Timer»). Esto es así porque podemos crear tantos contadores como queramos, cada uno con su propio nombre, y tenerlos todos a la vez en marcha.
Nelio Popups
¡Un plugin fantástico! Es muy fácil crear ventanas emergentes con el editor que ya conoces y las opciones que ofrece están muy bien diseñadas.
Juan Hernando
#3 Contadores automáticos
Si te interesa controlar el número de ejecuciones de alguna función en tu código, comprobar el número de pasadas que se hace por un bucle o simplemente contar algo, lo más sencillo es usar console.count. Cada vez que la función se ejecute, se sumará uno al contador que hayas especificado como parámetro:
console.counter.#4 Cómo formatear tus logs para hacerlos más inteligibles
Los logs están para ayudarnos a entender qué está pasando con nuestro código. Pero eso solo es posible si escribimos logs que luego podamos entender…
Cadenas de texto
Al principio de la entrada te habla de console.log (y los otros métodos para diferentes niveles de log). Todos los ejemplos que había puesto allí mostraban logs con texto:
console.log( 'Hello world!' );se convertía en:
Hello world!¿Pero qué pasa si queremos mostrar un objeto? Pues que también podemos, claro:
obj = { x: 1, y: { a: 'hola' } };
console.log( obj );se convierte en:
¿Pero qué pasa si queremos escribir varias cosas en el log? ¿Tenemos que usar múltiples llamadas a console.log? Pues la respuesta es: no, no es necesario. Podemos mostrar todo lo que queramos con una única llamada:
Agrupando logs…
Cuando empezamos a tener un montón de logs en nuestro código (como, por ejemplo, aquí):
el resultado puede acabar siendo un poco confuso, porque uno no sabe muy bien a qué parte pertenece cada cosa:
Retrieving x...
Retrieving y...
Compute result using 2 and 3
Getting max value
Result is 6Pero el objeto console nos ofrece un par de métodos para solucionar este problema: group i groupEnd. Con ellos, podemos agrupar los diferentes mensajes que escribimos:
para que aparezcan jerarquizados correctamente:
Tablas
Cuando trabajamos con colecciones de datos, no siempre es fácil visualizarlos. Por ejemplo, imagina que tenemos una lista de elementos como la siguiente:
data = [
{ id: 1, name: 'David', surname: 'Aguilera' },
{ id: 2, name: 'Ruth', surname: 'Raventós' },
{ id: 3, name: 'Antonio', surname: 'Villegas' },
];Si hiceramos un console.log de la lista, tendríamos algo tal que así:
console.log un objeto cualquiera, este se mostrará de una forma más o menos amigable.Que no es necesariamente malo, pero es claramente mejorable. Para este tipo de casos, lo mejor es usar console.table, ya que nos permite mostrar una información que es tabulable en, bueno, una tabla:
#5 Cómo mostrar correctamente tipos complejos (objetos y arrays) en el log
Finalmente, me gustaría acabar la entrada de hoy con algo que no muchos desarrolladores conocen y que, si se da el caso, puede hacerte perder un montón de tiempo tontamente. Pongamos, por ejemplo, que estás trabajando en un proyecto y quieres ver cuál es el valor de un objeto antes y después de actualizarlo. Para ello, es probable que metas un console.log de la variable antes de hacer el cambio y otro después, tal y como ves en el siguiente GIF:
Fíjate que en el primer log esperamos que attr sea 1 y en el segundo que sea 200. Y en principio, eso es lo que parece… pero, curiosamente, cuando expandimos el objeto en el log anterior a haber actualizado el valor, el objeto muestra el valor 200. ¿Qué está pasando?
Básicamente, que el mensaje de log que hemos mandado tiene una referencia al objeto y, por lo tanto, cuando lo expandimos nos mostrará el objeto tal cual es ahora y no como era cuando se hizo el log.
Para solucionar este problema, basta con que envíes una copia al log (con librerías como lodash y su método cloneDeep es muy fácil), ya que lo que estaremos enviando al log será una copia del objeto tal cual era en el momento en el que se hizo la copia:
¡Y eso es todo por hoy! Espero que te haya gustado la entrada. Si quieres más información sobre todo lo que puedes hacer con console, echa un vistazo a la documentación que hay en MDN.
No olvides compartirla con tus amigos ? Y si haces algo diferente o tienes algún consejo que compartir con nuestros lectores, déjanos un comentario ?
Imagen destacada de Tim van der Kuip en Unsplash.
Deja una respuesta