Depuración Web Moderna

Spanish audio is available in the player settings
Rate this content
Bookmark

Pocos desarrolladores disfrutan depurando, y la depuración puede ser compleja para las aplicaciones web modernas debido a los múltiples marcos, lenguajes y bibliotecas utilizados. Pero, las herramientas de desarrollo han avanzado mucho en facilitar el proceso. En esta charla, Jecelyn profundizará en el estado moderno de la depuración, las mejoras en DevTools y cómo puedes usarlas para depurar tus aplicaciones de manera confiable.

29 min
01 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Esta charla discute la depuración web moderna y las últimas actualizaciones en Chrome DevTools. Destaca nuevas características que ayudan a identificar problemas más rápido, mejora la visibilidad de archivos y el mapeo de fuentes, e ignorar y configurar archivos. El panel de puntos de interrupción en DevTools ha sido rediseñado para un acceso y gestión más fácil. La charla también cubre los desafíos de depurar con mapas de fuentes y los esfuerzos para estandarizar el formato de mapa de fuentes. Por último, proporciona consejos para mejorar la productividad con DevTools y enfatiza la importancia de informar errores y usar mapas de fuentes para depurar el código de producción.

Available in English

1. Introducción a la depuración web y DevTools

Short description:

Hola a todos. Hoy voy a hablar sobre la depuración web moderna y DevTools. Trabajo en el equipo de Chrome DevTools y comparto emocionantes actualizaciones sobre Chrome DevTools. Hace 15 años, el desarrollo web era diferente. Ahora usamos diferentes lenguajes y marcos. Compartiré herramientas para mejorar la depuración.

Hola a todos. Sí. Así que hoy voy a hablar sobre la depuración web moderna y DevTools. Entonces, mi nombre es Jesslyn. Este es mi manejador porque me gustan mucho los peces. Por eso mi manejador también es Jackfish.

Así que trabajo en el equipo de Chrome DevTools. Si en cada lanzamiento no solo descartaste esta pestaña de novedades, si haces clic en ella, podrías haber visto mi cara antes porque en cada nuevo lanzamiento compartiré algunas noticias emocionantes, actualizaciones emocionantes sobre Chrome DevTools y te mostraré algunos consejos sobre cómo hacer que seas productivo con Chrome DevTools.

Así que comencemos mi charla con esta captura de pantalla de hace 15 años. Así que estas son las DevTools hace 15 años. Notarás que hay muchas menos pestañas, muchos menos paneles que puedes usar. Y lo que es más interesante, también había algo llamado cripto. Así que la cripto comenzó desde ese tiempo, pero no realmente. El tiempo, ese tiempo cuando desarrollamos aplicaciones web, es mucho más diferente que cómo desarrollamos aplicaciones web ahora.

Por ejemplo, en aquel tiempo, cuando empezaste solo usábamos HTML, CSS y puro JavaScript para hacer desarrollo. Luego, después de eso, queríamos mejorar el rendimiento. Entonces comenzamos a comprimir y minimizar nuestro CSS y JavaScript. Vamos a los días, ahora, hoy en día lo que escribes no es exactamente lo que el navegador lee. Por ejemplo, usas diferentes lenguajes para escribir tus aplicaciones. Usas JSX, usas Spark, por ejemplo. Usas CSS o less para CSS. Usas TypeScript para reemplazar JavaScript. Y usas muchos marcos diferentes también, como Angular, React y Vue. E incluso tenemos meta marcos como Next y Nuxt también. Y todas estas herramientas necesitan pasar por un proceso para compilarlo y comprimirlo y transformarlo en lo que los navegadores pueden entender. Y también necesitamos Vue 2 como Vite, Webpack, rollout y ESVue, como muchas de estas herramientas para hacer que todo funcione.

Ahora, desde el día que comenzamos el desarrollo web hasta ahora que ya no estamos usando solo HTML, CSS y JavaScript para desarrollar tus aplicaciones, ¿qué pasa con la depuración? ¿Tenemos algún avance en la depuración también? Entonces, hoy, voy a compartir contigo algunas herramientas para mejorar tu depuración porque es importante. Este somos nosotros. Nosotros codificamos durante seis minutos probablemente, copiamos y pegamos, hacemos algunas investigaciones, revisamos GPT o Stack Overflow, pegamos el código dentro, pero simplemente no funciona y pasamos seis horas para depurarlo. Vale.

2. Nuevas características para una identificación de problemas más rápida

Short description:

Comencemos con algunas de las nuevas características que te ayudan a identificar problemas más rápidamente. Una de las cosas que harás durante la depuración es revisar la consola en busca de registros de errores. Anteriormente, los marcos irrelevantes abarrotaban la consola, lo que dificultaba la identificación de problemas. Ahora, ocultamos los marcos adicionales y mostramos solo lo que es relevante para tu aplicación. También puedes ver la pila de llamadas y ocultar marcos irrelevantes. Otra característica es la capacidad de ver tu código primero, acercándolo a tu IDE.

Comencemos con algunas de las nuevas características que te ayudan a identificar problemas más rápidamente. Entonces, una de las cosas que haces cuando te enfrentas a problemas durante la debugging, probablemente lo primero que harás es ir a la console para ver si hay algún registro de error en la console.

Entonces, imagina que vas a esta página y luego ves esta console. No es muy útil cuando estás desarrollando. Entonces, la primera captura de pantalla aquí es una captura de pantalla de la aplicación Angular, y la siguiente es de Vue.js. Entonces, permíteme abrir una aplicación de muestra aquí. Vale.

Entonces, por ejemplo, si hago clic en este botón de incremento. Si lo abro, esto es lo que vemos ahora. Entonces, anteriormente, si comparas esta aplicación con la anterior, te darás cuenta de que antes veías muchos frameworks irrelevantes como Zone.js, Async to Generator.js, como todos estos archivos JavaScript irrelevantes que pertenecen al framework en sí. Pero ahora, si abres esto, lo que hacemos es que ocultamos todos los marcos adicionales. Todos los marcos irrelevantes solo te muestran lo que sucede exactamente en tu aplicación, tus componentes. Entonces, por ejemplo, ves, como, te mostramos, como, el problema podría estar en el componente de la aplicación y en el componente del botón. Y si quieres ver el code del framework en sí, puedes hacer clic en Mostrar más marcos y abrir y revisar todos los demás también. Pero no tienes que hacerlo. Esto es lo que veías antes. Hay una larga lista hasta que puedes identificar dónde están los problemas.

Otra cosa que puedes hacer es que durante la debugging, también mejoramos el... Entonces, esta es una aplicación de Vue.js. Durante la debugging, tienes lo mismo... Tenemos las mismas características también. Entonces, por ejemplo, puse un punto de interrupción aquí. Si hago clic en Añadir, incremento el número. Puedes ver que en la pila de llamadas, a la derecha aquí, también ocultamos todos los marcos irrelevantes. Solo te mostramos lo que es relevante. Como, te mostramos las funciones de incremento, y te mostramos que actualmente estás en funciones de espera en el incremento. Y si quieres ver todos los marcos ignorados, puedes hacer clic en esto y expandir, y verás todos los demás que no son tan relevantes para lo que estás debugging en este momento. Y otra nueva característica que puedes probar es ver tu code primero. Algunos de los comentarios que recibimos es que, desde la vista aquí, como tu panel de fuentes aquí, lo que ves es lo que el navegador realmente lee mezclado con tu code real, cuando lo abres en el IDE. Entonces, si quieres ver la vista que se acerca más a tu IDE, lo que puedes hacer es hacer clic en este botón de archivo en el panel de fuentes, seleccionar agrupar por autor y desplegado.

3. Mejora de la visibilidad de archivos y mapeo de fuentes

Short description:

Mostramos tus archivos de componentes primero, facilitando su búsqueda y depuración. Las aplicaciones Angular también priorizan tus archivos y desenfocan los irrelevantes como los módulos de nodo. DevTools utiliza Source Map para mapear tus archivos comprimidos de vuelta a sus versiones originales, ignorando los archivos de framework especificados en la extensión Source Map. Angular y Nuxt lo soportan de forma nativa, mientras que Rollup y Webpack tienen plugins y opciones de configuración para ignorar archivos adicionales durante la depuración.

De esta manera, lo que hacemos es que te mostramos tus archivos de componentes primero o el archivo que tus archivos autorizados primero, lo que los navegadores muestran tu archivo desplegado lo empujarán hacia abajo para que puedas encontrar tu componente más rápido si quieres debug it.

Lo mismo ocurre con Angular también. Así que si vas a las aplicaciones Angular, haces clic en los tres puntos, lo agrupas por autor y despliegas, puedes ver que mostramos tu archivo web pack, tu archivo de fuentes, tu app, tu componente primero también. Y esto no es todo, ¿viste que realmente desenfocamos los módulos de nodo porque este es el archivo que quizás no quieras ver también.

Entonces, lo que puedes hacer aquí es que también puedes hacer clic en los tres puntos y ocultar todos los archivos que probablemente sean el code del framework. Puedes decir ocultar fuentes listadas para ignorar, y haces clic en él y ahora obtienes un árbol de páginas aún más limpio que te muestra solo tus archivos de origen. Vale.

Luego, la siguiente pregunta es cómo DevTools sabe qué ocultar. ¿Aplicamos AI para hacer eso o no? Así que usamos Source Map para hacer eso. Así que Source Map, en resumen, tengo un video para explicar qué son los Source Map y esto es una broma. Así que hay una fuente y hay un mapa que están apuntando. Así que hay Source Map. Sí.

Así que Source Map es el archivo que usamos para mapear tus fuentes desde las versiones comprimidas de tu archivo, mapearlo de vuelta a TypeScript o cualquier script que estés escribiendo. Así que este es uno de los ejemplos de Source Map. Si miras este archivo, hay un campo de fuentes que consiste en una matriz de diferentes archivos, diferentes archivos originales que estás escribiendo. Esto podría ser un archivo TypeScript o cualquier cosa. Así que en este caso, tenemos un archivo completo y un archivo library.js. Imagina que el archivo library.js es los archivos de los frameworks o cualquier biblioteca. Así que lo que los frameworks pueden hacer es que pueden agregar otro campo, lo llamamos extensión Source Map pero básicamente es un campo, para decirnos que, hey, este archivo, archivo lib.js, deberías ignorarlo. Así que siempre que los frameworks o las herramientas de construcción cuando generan el archivo de mapa de fuente, cuando llenan este campo, entonces las herramientas de desarrollo leerán ese campo e ignorarán el archivo en consecuencia. Por eso tienes la Cleaner Stack Trace. Así que el framework necesita decirnos esto. Y luego lo bueno es que si estás usando angular o nueces, es compatible, funciona de serie. No necesitas hacer nada. Y si usas read y roll up o webpack, webpack tiene un plugin también si quieres usarlo. Y también puedes, como para leer y enrollar, hay un campo como lista de ignorados de mapa de fuente que puedes usar para configurar algunos archivos adicionales que quieras ignorar durante la debugging. Así que este es un ejemplo del archivo roll up. Así que si, la fuente aquí es esta. Así que lo que puedes hacer es que puedes llenar tu, estas son funciones de lista de ignorados de mapa de fuente.

4. Ignorando y Configurando Archivos

Short description:

Puedes ignorar manualmente los archivos irrelevantes y configurar una lista de archivos ignorados en la configuración. Los archivos se muestran visualmente en gris para indicar su baja importancia durante el desarrollo. Cuando buscas archivos usando el comando P, los archivos ignorados también aparecen en gris.

Entonces puedes volver, puedes decir que para cualquier ruta que incluya nodos modules, simplemente ignóralo. O para cualquier ruta que incluya como una biblioteca de terceros, si no quieres debug simplemente añádelo allí y puedes empezar a ignorarlo. Vale. Eso es genial. ¿Y si soy un usuario de React? No mencioné, no mencioné nada sobre React ahora, ¿verdad? Entonces, ¿quién está usando, quién está usando React para el desarrollo? Vale, entonces casi la mitad de la sala. Vale. Estamos trabajando con el equipo de React para tenerlo listo para usar, pero aún no lo soporta. Lo que puedes hacer es hacerlo manualmente. Entonces, desde aquí, déjame mostrarte. Entonces, por ejemplo, digamos que esta es tu aplicación de React, y déjame mostrar también la altura. Entonces, digamos que uno de estos archivos, el archivo polyfield.ts, este es uno de los archivos que no quieres debug. Puedes hacer clic derecho en el archivo, y dices añadir este script para reconocer. Así es como puedes hacerlo, o si la carpeta del entorno, como toda la carpeta, no quieres debug. Puedes hacer clic derecho y añadir el directorio para reconocer. Esto tiene el mismo efecto que los navegadores hicieron con el XGoogleAcknowledge, pero en este caso, necesitas hacerlo manualmente una vez para que los navegadores recuerden tu configuración. Entonces puedes ignorar manualmente los archivos irrelevantes, y luego también puedes configurar una lista de archivos ignorados en la configuración. Así que una vez que ignoras el archivo, aparecerá un pop-up aquí. Puedes ver que si quieres eliminarlo del reconocimiento, puedes hacer clic y eliminarlo. Pero si quieres configurarlo, puedes hacer clic en configurar, y luego puedes abrir la configuración y puedes establecer tus propias reglas de exclusión personalizadas. Puedes añadir más o poner menos dentro. Puedes simplemente desactivarlo o simplemente eliminarlo por completo. Vale. Entonces, lo bueno es como mencioné justo ahora, y lo que acabas de ver, los archivos aparecen visualmente en gris para que sepas que estos son los archivos que no son tan importantes durante el desarrollo. Y cuando usas el comando P para buscar cualquier archivo, también pondremos en gris aquellos archivos que son no importantes también, que has ignorado. Vale.

5. Mejoras en el Panel de Puntos de Interrupción

Short description:

A continuación, discutiré algunas mejoras que hicimos en el panel de Puntos de Interrupción en DevTools. Rediseñamos la UX para proporcionar un acceso más rápido a las acciones comunes. Los puntos de interrupción ahora están agrupados por archivos, lo que facilita su identificación. Puedes desactivar o eliminar los Puntos de Interrupción por archivos, ahorrando tiempo. Hay tres tipos de Puntos de Interrupción: regulares, Condicionales y Lockpoint. Estas mejoras mejoran la experiencia de depuración en DevTools.

A continuación, quiero hablar un poco más allá de console.log. ¿Cuántos de ustedes usan console.log para debugging? Todos nosotros, ¿verdad? Así somos cuando debug en cualquier lugar, ¿alguien usa Punto de Interrupción para debugging? Bueno, no está mal, todavía hay muchas manos. Así que cada vez que hablamos de console.log, vemos que oh, todos levantan la mano y Punto de Interrupción es como, oh, no, sí, pero... Bueno, quiero hablar de algunas pequeñas mejoras que hicimos en el panel de Puntos de Interrupción para ayudarte a usar esta función un poco mejor. Así que lo primero es que rediseñamos el Punto de Interrupción UX para darte más acceso rápido a algunas acciones comunes. Así es el rediseño. Así que lo que hicimos es que ahora agrupamos el Punto de Interrupción por archivos. Si miras el ejemplo anterior, verás que simplemente te mostramos, como, un gran trozo de el archivo. Te mostramos un gran trozo de este archivo. Pero ahora lo agrupamos por archivo por archivo. Así que es más fácil para ti identificar qué archivo es. Y no solo eso, también puedes desactivar o eliminar el Punto de Interrupción por archivos. Lo que quiero decir con eso es que si vas a tu, por ejemplo, aquí, alguna vez querrás desactivar, como, por ejemplo, todos los Puntos de Interrupción dentro de un archivo. Lo que necesitas hacer es que necesitas ir a desplazarte por tu archivo y encontrar todos los Puntos de Interrupción y desactivarlo uno por uno.

6. Atajo para Lockpoint y Punto de Interrupción Condicional

Short description:

Añadimos un atajo para establecer un Lockpoint y un Punto de Interrupción Condicional. Anteriormente, tenías que hacer clic derecho en el archivo o usar un atajo largo. Ahora, simplemente puedes hacer clic en un punto con el comando para establecer el Punto de Interrupción más fácilmente. Si tienes alguna nueva característica en mente, háznoslo saber y podrías verlas en la próxima versión de DevTools.

O necesitas, como, hacer clic derecho en el archivo. Ahora, lo que hicimos es que añadimos alguna acción de atajo cuando pasas el ratón por el archivo. Y añadimos una función de desactivación aquí para que puedas desactivar todo de una vez. O también puedes eliminar todo de una vez.

¿Y cuántos de ustedes saben que hay tres tipos de Punto de Interrupción en DevTools? Vale. Genial. Hay buenas noticias para aquellos que también lo saben. Así que, hay tres tipos de Punto de Interrupción en DevTools. El primero es el Punto de Interrupción cuando haces clic en él, entonces estableces un Punto de Interrupción, eso está hecho. El otro tipo es el Punto de Interrupción Condicional. Así que, cuando quieres que se active el Punto de Interrupción, solo cuando llega a ciertas condiciones. Por ejemplo, necesitas estar en ciertos números. Y entonces, puedes usar este Punto de Interrupción Condicional para establecer tus condiciones de manera que no solo sigas rompiendo en él porque solo quieres romper cuando lo necesitas. Y el último es Lockpoint. Lockpoint es como Console.Lock, pero lo bueno es que no necesitas esparcir Console.Lock en tu code. ¿Y cuando haces check in, verdad? Entonces tal vez recibas algunas advertencias de que hay Console.Lock en tu code, por favor elimínalo. Usando Lockpoint, puedes hacerlo en DevTools y no necesitas añadir el... tiene las mismas características y no necesitas hacerlo en tu code.

Así que la buena noticia aquí es, añadimos un atajo para establecer un Lockpoint y un Punto de Interrupción Condicional. Permíteme mostrarte aquí. Así que, en la última conferencia a la que fui, tenemos este atajo que es usando el comando, opción B, para establecer el Punto de Interrupción Condicional y el Lockpoint Condicional. Pero entonces hay esto... uno de los asistentes simplemente me dijo, ¿qué tal si no nos das un atajo realmente largo? Solo dame... lo que quiero es que cuando hago clic en un punto solo soporte un clic de comando y luego solo ayúdanos a establecer el Punto de Interrupción más fácilmente. Sabes, esta es como una petición fácil pero simplemente, nuestro equipo nunca lo había pensado antes. Y ahora que añadimos el clic de comando. Así que, si tienes alguna nueva característica en mente, puedes hablar conmigo más tarde y decírnoslo. Probablemente lo verás en la próxima versión de DevTools. ¿Quién sabe? Vale.

7. Desafíos de Depuración y Mapas de Origen

Short description:

Puedes usar clic de comando para establecer Puntos de Interrupción condicionales o Lockpoints rápidamente. Los desafíos surgen al solucionar la experiencia de depuración debido a mapas de origen imperfectos. Los mapas de origen mapean archivos comprimidos de vuelta a sus versiones originales, pero a veces se eliminan variables. DevTools puede mostrar la vista previa y permitir la edición de valores para variables mapeadas, pero no para variables que no están en el mapa de origen. Los mapas de origen son un estándar oficial que no ha cambiado durante mucho tiempo.

Entonces, lo que puedes hacer aquí es que, en lugar de hacer clic derecho, puedes usar clic de comando en cualquier línea para establecer un Punto de Interrupción condicional o un Lockpoint. Y para hacerlo aún más rápido, lo que puedes hacer es que, junto a toda esta lista de Puntos de Interrupción, puedes hacer clic en el botón de edición para alternar la edición del Punto de Interrupción condicional o el Lockpoint. La última vez lo que necesitabas hacer es que necesitabas ir aquí y luego hacer clic derecho y luego agregar condición, editar las condiciones y cosas así. Ahora puedes simplemente usar clic de comando para hacer eso.

Vale. También quiero compartir con ustedes algunos desafíos que nuestro equipo cuando intentamos solucionar la experiencia de debugging, nos encontramos con algunos obstáculos y estamos tratando de resolver eso. El mapa de origen, como mencioné antes, no es perfecto. Entonces, por ejemplo, esta es una función. En esta función, en estas funciones de lectura aleatoria, tengo una variable de número y una variable de cuadrícula. Y uso ambas variables para calcular para mostrar la prueba, cuadrícula y número. Y en este caso, usarás algún minimizador o alguna herramienta de construcción para comprimirlo. Entonces este es tu archivo comprimido. Entonces, archivo JavaScript minimizado. Entonces lo que ves aquí es que ves hola E. Y lo que puedes ver es que la variable de número ahora se convierte en una variable más corta, E. Y tampoco hay una variable de cuadrícula. Porque la cuadrícula fue eliminada. Porque tu herramienta de construcción es tan inteligente, sabe que no la necesita durante el tiempo de ejecución. Entonces simplemente lo elimina por completo. Esto está bien si no debug tu code. Pero si estás debugging tu code, esto a veces puede suceder. Por ejemplo, aquí, cuando estás debugging en las funciones, lo que DevTools hará es que para el número, podemos mostrarte la vista previa del valor, y puedes editar el valor en el panel de alcance también. Pero no podemos hacer eso para la cuadrícula. Porque esta información no está mapeada en absoluto. Esta información no está en el mapa de origen en absoluto. Y es imposible para nosotros conocer esta variable. Porque solo sabremos información para mapearla. Entonces, para tu información, el mapa de origen es un estándar oficial. Aunque nuestro desarrollo cambió durante muchos años. Pero la especificación del mapa de origen no está cambiando durante mucho tiempo.

8. Estandarización de los Mapas de Origen

Short description:

Desde 2011, hemos estado trabajando en la estandarización del formato de los mapas de origen para mejorar la experiencia de depuración. La especificación actual tiene cierta ambigüedad, lo que lleva a interpretaciones ligeramente diferentes y a la generación de mapas de origen distintos. Nuestro objetivo es evolucionar y fortalecer la especificación, y asegurar que todas las herramientas generen mapas de origen en un formato estandarizado.

Como, desde 2011, han pasado 12 años. No ha cambiado mucho. Y lo que estamos haciendo actualmente es que... Hay algunos equipos que actualmente están tratando de estandarizar el mapa de origen, trabajar con una organización de web standards para estandarizarlo, de modo que diferentes herramientas, diferentes build tools o TypeScript o cualquier herramienta cuando generen nuestro mapa de origen, esté en el formato en el que todos estén de acuerdo. La especificación actual del mapa de origen tiene cierta ambigüedad en los términos en sí, por lo que todos interpretan de manera ligeramente diferente y generan mapas de origen ligeramente diferentes. Y también estamos trabajando en la evolución del mapa de origen, endureciendo la especificación, y para mejorar la experiencia de debugging. Por lo tanto, necesitamos que las herramientas de construcción y otras herramientas trabajen juntas para mejorarlo.

9. Herramientas de Desarrollo para la Productividad

Short description:

En esta parte, compartiré dos consejos para mejorar tu productividad. El primer consejo es utilizar la función de alternar la clase CSS, que te permite probar diferentes estilos de clase en una página web. El segundo consejo es sobrescribir el encabezado de respuesta HTTP utilizando el panel de red, que es útil cuando se trata de errores de origen CORS. Puedes editar y agregar encabezados para continuar el desarrollo mientras esperas los cambios en el backend. Esta función también es aplicable para cargar archivos JSON.

Bien. La última parte es sobre las herramientas de desarrollo para productivity. Así que quiero compartir contigo algunos tips para mejorar tu productivity. Bien. Así que el primero, comienza con la clase de alternancia CSS. ¿Quién aquí usa Tailwind CSS? Bien. Si usas Tailwind CSS, déjame abrir la página de Tailwind. O si no lo haces, funciona para todos los demás archivos CSS también así que esta es la página web de Tailwind. Así que lo que hago aquí es que me enfoco en esto y luego puedes usar, puedes alternar esta clase y lo que puedes hacer aquí, puedes simplemente intentar alternar diferentes clases para probar en las diferentes características. Y lo que puedes hacer, también puedes escribir como, por ejemplo, quiero establecer el fondo así que te mostrará todas las clases que has definido para el fondo. Y si quieres eliminar, quieres que el texto esté centrado, puedes usar este campo de clase de punto, alternarlo, abrirlo y luego alternar la clase y jugar con ella. Así que, esta es una de las características que puedes usar.

Y otra es la de sobrescribir el encabezado de respuesta HTTP. Así que, creo que la mayoría de nosotros en nuestro viaje de desarrollo, hemos topado con este error antes. Déjame refrescar esta página. Oh, no, ¿está bien? Bien. Así que, hemos topado con estos errores de origen CORS. Oh, no hay errores ahora. ¿Dónde están mis errores? ¿En serio? Oh, sí, el error está aquí. Así que, dice que esto, que hay algunos controles de acceso permiten orígenes aquí que no funcionan. Así que, lo que necesitamos hacer aquí, a veces simplemente vas al backend o si eres un ingeniero de frontend le pedirás al backend que agregue algunos encabezados CORS en el backend. Digamos que solo quieres seguir desarrollando. Quieres sobrescribir eso en el frontend mientras esperas los cambios en el backend. Lo que puedes hacer ahora es ir al panel de red, hacer clic en la solicitud, puedes editar, puedes sobrescribir el encabezado para agregar lo que quieras. Así que, en este caso, lo que hago es que agregaré un encabezado, agregaré el encabezado de origen de acceso CORS y simplemente lo estableceré en todo porque solo quiero continuar con mi desarrollo. Y lo que hago aquí, si refresco la página, verás, comenzará a cargar todos los archivos JSON en absoluto. Sí. Genial. Esta es una característica realmente nueva que puedes usar. Y no solo eso, puedes hacer básicamente lo mismo para JSON dummy porque solo lo hacemos para To-Do JSON.

10. Uso de la Sobreescritura de Encabezado y Fragmentos de JavaScript

Short description:

Podemos sobrescribir el origen de acceso para archivos JSON ficticios. En el panel de DevTools, puedes guardar fragmentos de JavaScript para ejecutar funciones repetidamente. Por ejemplo, puedes resaltar el panel de contenido más grande en cualquier página utilizando un fragmento. Otro fragmento puede recuperar y ordenar imágenes en una página. Intenta usar fragmentos de JavaScript para simplificar tu flujo de trabajo. Por último, escribir una función de búsqueda en YouTube y depurar desde allí puede ser una técnica efectiva.

Podemos hacer lo mismo para JSON ficticio. Lo que es aún mejor es que puedes hacer clic en este enlace de sobreescritura de encabezado y te llevará a este archivo. Básicamente es un archivo. Así que lo que hacemos es que puedes cambiar este aplicar a para cambiarlo a un comodín. Así que dices, como, todos los archivos JSON, quiero cambiar el origen de acceso. Así que solo refrescaré. Verás, ahora después de cambiarlo, puedes cargar el archivo dummy.json también sin ningún esfuerzo. ¿Bonito, verdad?

Bien. Y otra cosa es que en el panel de DevTools, también admite fragmentos de JavaScript. Así que este fragmento de JavaScript, lo que puedes hacer es ahorrarte mucho tiempo, especialmente hay algunas funciones que necesitas ejecutar una y otra vez. Puedes simplemente guardarlo como un fragmento. Así que por ejemplo, en esta página, tengo un fragmento de getImages, tengo un fragmento de getLCPS. Así que siempre quiero obtener el panel de contenido más grande en esta página. Así que tengo este fragmento aquí que me ayudará a resaltarlo. Así que no importa en qué página esté, por ejemplo, estoy en el panel de Elementos. Si quiero ejecutar estas funciones, lo que necesito, una vez que guardo el fragmento, lo que puedo hacer es puedo hacer clic en Command P y luego puedo usar el signo de exclamación y luego simplemente ejecutar la función. Así que por ejemplo, getLCP en este caso. Así que en este caso, simplemente resaltará las cosas de LCP más grandes para mí porque sé que como ingeniero de performance, esta es la función que ejecutaré una y otra vez de nuevo. Así que simplemente lo guardo. Así que por ejemplo, tengo otra función para obtener imágenes. Así que en esta función, cuando la ejecuto, obtendrá todas las imágenes de esta página y luego puedo ordenar la página, ordenar el tamaño para que pueda ver cuáles son las imágenes que puedo eliminar de esta página. Así que pruébalo. Usa el fragmento de JavaScript para facilitarte la vida.

Y la última, esta en la última conferencia, cuando compartí esto, recibí muchos aplausos. Veamos si esta recibe más aplausos que la sobreescritura. Así que vamos a YouTube. Lo que a veces hacemos es que queremos escribir una función de búsqueda aquí. Y desde aquí, es posible que quieras debug. Hay algunos problemas aquí. Quieres debug esto.

11. Devolviendo el Enfoque a la Página y Consejos de Depuración

Short description:

Para devolver el enfoque a la página, haz clic en el menú de tres puntos, saca el panel de renderizado y selecciona la función 'emular una página enfocada'. Otra opción es usar comandos, como 'command shift P', para acceder al panel de comandos y ejecutar acciones. Recuerda informar de los errores y problemas al equipo de DevTools. Al depurar código de producción o minimizado, genera y guarda un mapa de origen en un lugar seguro. Luego, en el panel de fuentes, adjunta el mapa de origen para depurar el código.

Pero cuando haces clic en el elemento al que quieres enfocarte, desaparece. Así que lo que puedes hacer aquí es que puedes hacer clic en el menú de tres puntos, sacar el panel de renderizado, hay una función llamada emular una página enfocada aquí. Así que esta función te ayuda a devolver el enfoque a la página en lugar de en la herramienta de desarrollo. Así que si haces clic en ella, ¡bam! Seguirá mostrándose y podrás editarla. Te digo, estas características han estado ahí durante diez años o muchos años y... Sí. Antes incluso de que me uniera a Google. Sí. Así que esta es una buena característica.

Y si no recuerdas la pestaña de renderizado, lo último que puedo decirte es que todo es un comando. Así que puedes usar el comando, básicamente, puedes usar command shift P para sacar el panel de comandos para ejecutarlo. Y si no recuerdas este comando, siempre puedes hacer clic en el menú de tres puntos, hacer clic en ejecutar comando, y puedes hacer clic, como, en enfocar página. Y no emular la página enfocada y emular la página enfocada, o quieres configurar la página para, como, cambiar DevTools al Equipo Doug. Solo saca eso y básicamente puedes ejecutar cualquier comando, abrir un panel y hacer algunas acciones solo con el panel de comandos en sí. Ve a ejecutar comando. Bien, con eso, me quedan 38 segundos.

Y esto es lo último. Voy a, como, conferencias, mucha gente me dice, nunca informo de los errores. Y DevTools simplemente los arreglará automáticamente. Hay algunos errores que son realmente molestos. Pero simplemente piensas que no necesitas informar de ello, y el equipo de DevTools lo sabrá. Desafortunadamente, no somos AI, así que si tienes algún problema, informa de ello en esta URL o simplemente twittea en Chrome DevTools para que nuestro equipo sepa que tienes estos problemas y podamos solucionarlo. Eso es todo. Y hay un enlace para las diapositivas si quieres tomar las diapositivas. Y gracias a todos.

Una pregunta para ti. ¿Cuál sería tu mejor consejo para debugging código de producción o minimizado? Si vas a debug un código de producción o minimizado, lo que puedes hacer es que puedes generar un mapa de origen y guardarlo en un lugar secreto. Y luego cuando realmente quieras debug it, puedes, en el panel de fuentes, puedes hacer clic derecho en cualquier archivo JavaScript, hacer clic en adjuntar mapa de origen, y puedes adjuntar tu mapa de origen del código de producción para depurar tu código. Así es más fácil. Y puedes ocultar tu mapa de origen a cualquier otra persona. Solo adjúntalo cuando necesites depurar tu código de producción. Increíble. Gracias. Y luego hubo claramente mucho interés. Así que si tienes preguntas, por favor acércate al stand o encuéntrame más tarde en tus redes sociales o algo así. Y muchas gracias por la charla. Gracias. Fue genial. Un último aplauso, por favor. Gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript
You will learn about one of the most popular package managers for JavaScript and its advantages over npm and Yarn.A brief history of JavaScript package managersThe isolated node_modules structure created pnpmWhat makes pnpm so fastWhat makes pnpm disk space efficientMonorepo supportManaging Node.js versions with pnpm
React Advanced Conference 2021React Advanced Conference 2021
27 min
Beyond Virtual Lists: How to Render 100K Items with 100s of Updates/sec in React
Top Content
There is generally a good understanding on how to render large (say, 100K items) datasets using virtual lists, …if they remain largely static. But what if new entries are being added or updated at a rate of hundreds per second? And what if the user should be able to filter and sort them freely? How can we stay responsive in such scenarios? In this talk we discuss how Flipper introduced map-reduce inspired FSRW transformations to handle such scenarios gracefully. By applying the techniques introduced in this talk Flipper frame rates increased at least 10-fold and we hope to open-source this approach soon.
JSNation 2022JSNation 2022
30 min
High-Speed Web Applications: Beyond the Basics
Knowing how to run performance tests on your web application properly is one thing, and putting those metrics to good use is another. And both these aspects are crucial to the overall success of your performance optimization efforts. However, it can be quite an endeavor at times for it means you need to have a precise understanding of all the ins and outs of both performance data and performance tooling. This talk will shed light on how to overcome this challenge and walk you through the pitfalls and tricks of the trade of Chrome DevTools, providing you with a complete roadmap for performance analysis and optimization.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
JSNation 2022JSNation 2022
71 min
The Clinic.js Workshop
Workshop
Learn the ways of the clinic suite of tools, which help you detect performance issues in your Node.js applications. This workshop walks you through a number of examples, and the knowledge required to do benchmarking and debug I/O and Event Loop issues.
JSNation 2023JSNation 2023
44 min
Solve 100% Of Your Errors: How to Root Cause Issues Faster With Session Replay
WorkshopFree
You know that annoying bug? The one that doesn’t show up locally? And no matter how many times you try to recreate the environment you can’t reproduce it? You’ve gone through the breadcrumbs, read through the stack trace, and are now playing detective to piece together support tickets to make sure it’s real.
Join Sentry developer Ryan Albrecht in this talk to learn how developers can use Session Replay - a tool that provides video-like reproductions of user interactions - to identify, reproduce, and resolve errors and performance issues faster (without rolling your head on your keyboard).