Video Summary and Transcription
La charla de hoy se centró en construir mejores herramientas de desarrollo de React con análisis de viaje en el tiempo de Replay. Las DevTools de React proporcionan valiosos conocimientos sobre las aplicaciones de React, utilizando una estructura de datos de fibra para representar instancias de componentes. Replay es un depurador de viaje en el tiempo para React, con planes de hacer de Chrome su navegador principal de grabación. Extraen información de React de las grabaciones utilizando su API de viaje en el tiempo y han construido una interfaz de usuario para la depuración y la inspección del contenido. El objetivo a largo plazo es que Replay funcione sin conexión y en modo de grabación permanente.
1. Introducción a la Construcción de Mejores Herramientas de Desarrollo de React
Hoy, hablaré sobre la construcción de mejores herramientas de desarrollo de React con análisis de viaje en el tiempo de reproducción. Redux Toolkit 2.0 está en beta, y agradecemos sus comentarios. Las DevTools de React son una herramienta valiosa para entender tu aplicación de React.
Muy bien, buenas tardes, muchas gracias. Mi nombre es Mark Eriksson, y hoy estoy muy emocionado de hablarles sobre la construcción de mejores herramientas de desarrollo de react con análisis de viaje en el tiempo de reproducción, los cambios de título, lo que sea. Gracias por estar aquí. Seré honesto, probablemente esta no será la charla más práctica. No hay muchas cosas. Es como si pudiera ir a casa e inmediatamente cambiar mi código.
Definitivamente vamos a profundizar hoy. Tendré las diapositivas en mi blog más tarde hoy, blog.i2software.com, y estaré muy contento de responder preguntas sobre esto más tarde. Un par de cosas rápidas sobre mí. Soy un ingeniero frontend senior en Replay, donde estamos construyendo un depurador de viaje en el tiempo para JavaScript, y hablaremos de eso. Responderé preguntas en cualquier lugar donde haya un cuadro de texto en internet. Recojo todo tipo de enlaces interesantes. Escribo publicaciones de blog ridículamente largas, y soy un mantenedor de Redux, pero la mayoría de la gente me conoce como el tipo con el avatar de Los Simpsons.
Por curiosidad, ¿cuántas personas... llegaremos a las cosas de React en un segundo. Una nota rápida. Redux Toolkit 2.0 está en beta. Realmente apreciaríamos que la gente lo probara y nos diera sus comentarios. Háganos saber cómo funciona la nueva característica. Danos feedback si deberíamos intentar cambiar algunos de los diseños de API antes de que sea definitivo. Por favor, pruébalo y déjanos saber cómo funciona. ETA pronto. ¿Cuántos de ustedes tienen la extensión DevTools de React instalada en su navegador? Bien, esas son la mayoría de las manos. Muy contento de ver eso. Las DevTools de React son una maravillosa ayuda para entender lo que está pasando en tu aplicación de React. Es una de las grandes ventajas que tienen sobre los frameworks anteriores como Backbone. ¿Qué son? Nos permiten inspeccionar el árbol de componentes en la página. Nos muestran las relaciones de parentesco, el orden de los componentes, y si seleccionas un componente, entonces te mostrará las props actuales, los hooks, el estado, incluso algo llamado el árbol del propietario, que es la cadena de componentes que lo renderizó. Es una herramienta extremadamente valiosa para entender tu aplicación de React.
2. Entendiendo las Herramientas de Desarrollo de React
Las herramientas de desarrollo de React tienen un panel de perfil que muestra el número de renders, los componentes renderizados y su tiempo de renderizado. Utiliza una estructura de datos llamada fibra para representar instancias de componentes. React se comunica con la extensión del navegador a través de un objeto de gancho global, lo que le permite enviar información sobre los renders. El árbol de fibras tiene punteros a la versión anterior, lo que permite a la extensión comparar los árboles actuales y anteriores durante la fase de compromiso.
Las herramientas de desarrollo de React también tienen un panel de perfil. Puedes presionar el botón de grabar, usar la aplicación durante un minuto, y te mostrará una lista o un recuento de todas las veces que la aplicación se renderizó, y para cada renderizado, te mostrará qué componentes en el árbol se renderizaron, y cuánto tiempo tardó cada uno de ellos. El gráfico de llama te da una idea relativa de este componente que tardó el doble que aquel. Muy valioso para entender el rendimiento general de tu aplicación.
Pero, ¿cómo funciona esto? Magia. Bueno, no es realmente magia, sino un montón de ingeniería muy cuidadosa. Entonces, sabemos que los componentes de función y los componentes de clase existen. Pero en muchos aspectos, estos son solo una especie de fachadas sobre los datos reales. Internamente, React tiene una estructura de datos llamada fibra. Y cada fibra representa una instancia de componente en el árbol. Así que React almacena el tipo de componente, literalmente la función o la clase. Almacena las props actuales. Tiene una lista enlazada que apunta a los padres, hermanos e hijos, y un montón de otros metadatos internos. Y así, este es realmente el árbol real de los componentes. Cada vez que React termina un renderizado, tiene este árbol de fibras que representa las instancias de componentes. Entonces, cuando instalas la extensión del navegador, React, que se carga en todas las páginas e inyecta algo de JavaScript. Y esto crea una variable global, doble guión bajo React DevTools gancho global, doble guión bajo. Y así es como React en la página va a hablar con la extensión del navegador. Entonces, este objeto de gancho global, que por cierto, no tiene nada que ver con los ganchos, como usar lo que sea, es solo una colisión de nombres. Almacena referencias a cada copia diferente de React que está en la página. Tiene algunas capacidades de emisor de eventos y tiene algunos callbacks que React ejecutará cada vez que haya renderizado. Entonces, cuando cargas React en la página, una de las primeras cosas que hace, es buscar, ¿existe este objeto de gancho global? Y si es así, sabe que la extensión del navegador está allí y tratará de enviar la información más tarde. Entonces, cada vez que React termina de renderizar al final de la fase de compromiso, hablará con el gancho global y ejecutará este método on commit fiber root. Y pasa por encima de la fibra de nivel superior que representa el componente raíz para todo el árbol. Y ahora, en ese punto, la extensión del navegador tiene algún código que se ejecuta dentro de la página, y puede mirar el árbol de componentes y ver qué hay allí y cómo se veía el árbol antes de eso. Entonces, ¿cómo sabe cómo se ve el árbol de componentes? Quiero decir, es obvio. Está justo allí. Todos podemos leer esto, ¿verdad? Entonces, el árbol de fibras en realidad tiene punteros a la versión anterior del árbol del último compromiso también. Y así, durante la fase de compromiso, cuando ejecuta este callback, el código de la extensión en la página puede recorrer el árbol y hacer un diff para comparar aquí estaba el árbol la última vez versus aquí está el
3. Entendiendo las Herramientas de Desarrollo de React y Replay
Las herramientas de desarrollo de React utilizan un formato de operaciones con códigos numéricos para transmitir de manera eficiente información sobre los cambios en la estructura del árbol de componentes. Al seleccionar un componente, la interfaz de usuario de la extensión envía una solicitud a la página, y el código de la extensión describe la fibra y envía datos sobre props, hooks y estado. Además de las Herramientas de Desarrollo de React, Replay está construyendo un depurador de viaje en el tiempo que permite la grabación y depuración de aplicaciones con capacidades de viaje en el tiempo.
esta vez. Y está tratando específicamente de entender qué partes de la estructura del árbol cambiaron. Qué componentes se agregaron, o se eliminaron, o se reordenaron. Y va a intentar describir esto de una manera muy eficiente. Porque podrían haber cientos de componentes que cambiaron, y necesita enviar esa información desde el proceso principal del navegador al proceso de la interfaz de usuario de la extensión. Y eso podría ser un montón de data para serializar. Así que las React dev tools tienen un formato de operaciones que es todo códigos numéricos estrictos. Y así, si desglosamos este array, un array de operaciones típico contiene estas variables. Está el ID de esta copia de React en la página. Está el ID de la raíz de React. Porque podrías haber dicho renderizar algo de React renderizar algo de React por allá. Y luego tenemos que tener todas las cadenas para los nombres de los componentes. Entonces, dice que hay cinco nombres de componentes únicos que son nuevos en este commit. Y luego tiene los códigos numéricos UTF para cada carácter. Así, como lista de tareas o elemento de la lista de tareas. Luego vamos a describir cada cambio en el árbol como una operación única. Entonces, vamos a agregar un componente de elemento de la lista de tareas. Es un componente de función. Su padre tiene este ID, el propietario tiene un ID, y luego tenemos que tener los índices en la tabla de cadenas para que sepa qué nombre está asociado con ese componente. Y así, esta es una manera muy eficiente de transmitir toda esa información. Entonces, un array de operaciones típico podría tener potencialmente cientos de operaciones separadas y ser miles de números de largo. Pero esto solo tiene la información sobre la estructura del árbol. No tiene información sobre los detalles. Entonces, cuando seleccionas un componente, la interfaz de usuario de la extensión envía una solicitud asíncrona a la página y el código de la extensión en la página mira la fibra, la describe y envía los data de vuelta a la interfaz de usuario para decir aquí están tus props y tus hooks y tu estado. Así que, esos son los fundamentos de cómo funcionan las React DevTools. Pasemos al modo de ventas. Entonces, mi trabajo diario es trabajar en Replay, donde estamos construyendo un depurador de viaje en el tiempo. Y la idea es, te grabas usando tu propia aplicación durante un par de minutos con nuestras versiones modificadas de Chrome o Firefox. Y una vez que has hecho eso, puedes debug la grabación con superpoderes de viaje en el tiempo. Puedes saltar a cualquier línea de código en la grabación, puedes ver cuántas veces se ejecutó, puedes agregar declaraciones de impresión sin cambiar el código, y registra lo que habría registrado cada vez que esa línea de código fue golpeada, puedes ver mensajes de consola y elementos DOM, y puedes ver el árbol de componentes de React
4. Replay: El Mejor Depurador para React
Replay es un depurador para React, utilizado por el equipo central de React y los desarrolladores en Next.js. Comenzó con soporte para Firefox, pero la implementación no era mantenible. Ahora, Replay tiene una API que proporciona superpoderes de viaje en el tiempo como una API. Están trabajando en hacer de Chrome su navegador de grabación principal.
en cada momento. Esto registra todo en el navegador. No es específico del marco. Puedes usarlo con Vue, Angular, jQuery, lo que sea. Pero nosotros usamos React. Estamos muy involucrados en la comunidad de React, y nuestro objetivo es hacer de Replay el mejor depurador para React, punto.
Ahora, sé de hecho que algunos de los miembros del equipo central de React han usado Replay, y varios de los desarrolladores en Next.js han usado Replay. De hecho, Tim Newkins, uno de los líderes en Next, tuiteó a principios de este año que cuando lanzaron Next 13.4 con el enrutador de la aplicación, tuvieron algunos bugs muy complicados, y la única forma en que pudieron solucionarlos fue usando Replay para hacer grabaciones de Next, rastrear algunos problemas relacionados con el tiempo, y solucionarlos.
Así que, nuestro primer navegador de grabación fue Firefox. Nuestros fundadores comenzaron como ingenieros de DevTools de Firefox. Y cuando me uní a Replay hace un año y medio, teníamos soporte para React DevTools. Pero la forma en que lo implementamos no era muy mantenible. De hecho, copiamos y pegamos todo el paquete de extensión de React DevTools en el código fuente de Firefox, y lo cargamos en cada página, de modo que cada vez que hacías una grabación, la extensión estaba allí y React guardaría los data. Y luego capturamos los data y los guardamos en este pequeño formato de objeto llamado anotación para persistirlo en nuestro servidor. Y de esa manera teníamos las marcas de tiempo de cada vez que React se actualizaba, y teníamos una copia de todos estos arrays de operaciones. Y funcionó, pero había algunas limitaciones. Ralentizó un poco el proceso de grabación. Tenías que tener las mismas versiones del código de las herramientas de desarrollo en Firefox y en nuestra interfaz de usuario para leer los data, y es difícil actualizar los paquetes. Así que, Replay tiene una API. Como, toda la magia ocurre en la cloud. Y básicamente te da superpoderes de viaje en el tiempo como una API. Así que, tiene todos estos métodos para pausar un proceso de navegador, pedir los marcos de pila y las variables y los ámbitos, y todas estas otras cosas. Esto está documentado públicamente. Cualquiera podría sentarse y escribir scripts que usen esto ahora mismo. Y toda nuestra interfaz de usuario está construida sobre este protocolo. Así que, hemos empezado a trabajar en tratar de hacer de Chrome nuestro navegador de grabación principal. Funciona genial para Linux ahora mismo. Windows todavía está en alfa temprana. Todavía hay algunas características que necesitamos para alcanzar la paridad. Pero a finales del año pasado, estábamos hablando de ello. Es como, no tenemos soporte para las herramientas de desarrollo de React en nuestra bifurcación de Chrome todavía. No nos gusta la idea de copiar y pegar el
5. Extrayendo Información de React de la Grabación
Utilizamos nuestra API de viaje en el tiempo para extraer información de React de una grabación de la aplicación. Iniciamos un proceso en segundo plano para extraer datos de la grabación y capturar marcas de tiempo. Guardamos las marcas de tiempo de renderizado de React y utilizamos un objeto de gancho falso de React DevTools. Configuramos un andamiaje para extraer datos utilizando nuestro protocolo y guardarlo para la interfaz de usuario del cliente. Ejecutamos código a través de eval, enviando una cadena de código al navegador en pausa en la grabación.
paquete. Seguramente, tiene que haber una mejor manera de hacer esto. Entonces, la idea era, ¿qué pasaría si usáramos nuestra API de viaje en el tiempo para extraer toda la información de React de una grabación de la aplicación y guardarla para su uso en nuestro cliente de depuración. Así, no hay ninguna extensión instalada en Chrome. Vamos a tener que encontrar una manera de procesar la grabación y extraer estos datos. No sabemos cuándo React realmente se renderizó, ¿y cómo obtenemos esos valores de operaciones de todos modos? Así que, nuestra idea era que en nuestro servidor backend cada vez que alguien abre una grabación para depurarla, vamos a iniciar un pequeño proceso adicional en segundo plano que utiliza nuestras APIs para extraer los datos. Y entonces, para hacer eso posible, vamos a tener que poner código en nuestra bifurcación de Chrome para capturar marcas de tiempo para que incluso sepamos en qué puntos en el tiempo React se comprometió durante la grabación. Así que, la mayoría de nuestras modificaciones a Chrome están en un archivo de 6,000 líneas que es una mezcla de C++ y JavaScript dentro de cadenas de C++, lo cual es horrible. Pero, entramos, principalmente yo, y creé, como, una pequeña versión falsa del objeto de gancho de React DevTools. Y eso se carga en cada página, de modo que React, durante la grabación, piensa que está hablando con la extensión. Pero, durante el proceso de grabación, sólo está guardando marcas de tiempo, React renderizó, React renderizó, React renderizó. De esa manera, sabemos, más tarde, en qué puntos en el tiempo realmente importan. Hay un montón de piezas adicionales de contabilidad complicadas. Tengo que hacer algunos ahorros de variables de fibra de React y variables de renderizado para guardar para más tarde, pero son quizás 100 líneas de código. No está tan mal. Así que, en el backend, configuramos un andamiaje para que cada vez que un usuario abre una grabación por primera vez y no tenemos ningún dato guardado, iniciamos un proceso en segundo plano que tiene acceso a nuestro protocolo y ahora puede empezar a llamar a estas APIs de análisis para extraer datos. Ahora, podrías escribir cualquier script de Node independiente que use nuestro protocolo. De hecho, tenemos algunos ejemplos en un repositorio que hemos reunido. Pero conceptualmente, una rutina es sólo como un proceso en segundo plano que puede llamar a métodos de protocolo. Así que, la idea básica es que primero obtenemos todas estas anotaciones con las marcas de tiempo. Luego vamos a tener que realmente enviar una copia del código de React DevTools JavaScript a este navegador en pausa en la grabación. Y luego para cada commit, vamos a pedir a ese paquete, dame todas las operaciones para ese commit. Tenemos que hacer un poco más de reformateo en los datos. Y luego finalmente, podemos guardar esta información para que pueda ser utilizada por nuestra interfaz de usuario del cliente. Entonces, ¿cómo se ejecuta el código a través del viaje en el tiempo? Y es la herramienta favorita de todos, eval. Ahora, por supuesto, nos han dicho durante años que usar eval es malo, y malvado, y peligroso, y un riesgo de seguridad. Y probablemente sea cierto. Pero en este caso, es el martillo que resuelve todo. Así que, puedes enviar, como un eval es sólo, aquí tienes una cadena de código, hey JavaScript intérprete, por favor ejecuta esto como si fuera código real. Podemos enviar una cadena de código a través de la red y ejecutarla dentro de un navegador en pausa en la grabación en la nube y realmente funciona. Así que, en este ejemplo, sólo estoy evaluando como una pequeña cadena y son unas pocas líneas.
6. Depuración de la Grabación y React en la Interfaz de Usuario
Y puedo devolver resultados de ese eval. Luego, nuestro protocolo nos permite inspeccionar el contenido. ¿Era un primitivo? ¿Era un objeto? ¿Un array? ¿Cuáles son los campos de ese objeto? Y podemos obtener todos los detalles. El código de evaluación puede mutar el entorno en pausa. Si cambio una variable o añado algo a un global, se mantiene para más tarde. Esto es importante porque si puedes evaluar una pieza de JavaScript de cinco líneas, puedes evaluar un paquete de JavaScript minimizado de 150K. Escribir códigos en cadenas no es mantenible. Hemos escrito estas funciones en TypeScript, eliminado los tipos en tiempo de compilación y las hemos evaluado como funciones de JavaScript simples. Hay que tener cuidado de no cerrar sobre ninguna otra variable. Vamos a complicarlo mucho. Nuestro protocolo da IDs numéricos para cualquier objeto, pero no sabe si una variable es la misma referencia en diferentes puntos en el tiempo. Modificamos Chrome para darnos IDs de objeto persistentes. Hicimos un fork de las React DevTools, modificamos sus internos y eliminamos código innecesario para reducir el paquete. React necesita estar en la página para depurar la grabación desde nuestra interfaz de usuario.
Y puedo devolver resultados de ese eval. Luego, nuestro protocolo nos permite inspeccionar el contenido. ¿Era un primitivo? ¿Era un objeto? ¿Un array? ¿Cuáles son los campos de ese objeto? Y podemos obtener todos los detalles. El código de evaluación puede mutar el entorno en pausa. Si cambio una variable o añado algo a un global, se mantiene para más tarde. Y esto es importante. Porque si puedes evaluar una pieza de JavaScript de cinco líneas, puedes evaluar un paquete de JavaScript minimizado de 150K.
Y ahora, escribir códigos en cadenas es muy poco mantenible. Y este es en realidad un problema que tuvimos cuando me uní a Replay. Lo que descubrí, una de las peculiaridades del lenguaje JavaScript es que si llamas a cualquier función .toString, obtienes una cadena de la declaración de la función y su código fuente. Lo que significa que puedes enviar esa cadena a través de la red. Y lo que hemos hecho es que hemos escrito estas funciones en TypeScript. En tiempo de compilación, los tipos se eliminan y es solo una función simple de JavaScript. Y luego haces function.toString y luego la evalúas y simplemente funciona mágicamente. Es genial. Tienes que tener cuidado, no puedes cerrar sobre ninguna otra variable. La función tiene que ser autónoma. Ahora vamos a complicarlo mucho. Así que puedes pausar la grabación en muchos puntos en el tiempo y nuestro protocolo devuelve IDs numéricos para cualquier objeto. Pero no sabe que una variable es la misma referencia en dos diferentes puntos en el tiempo, podría ser un ID de objeto diferente cada vez. Así que en realidad tuvimos que modificar Chrome para que nos diera consistentemente IDs de objeto persistentes a lo largo de muchos puntos en el tiempo. Excepto que lo único que hemos hecho es objetos React Fiber específicamente para esto. Eventualmente vamos a añadir IDs persistentes en el backend para cualquier objeto en cualquier momento. Todavía no tenemos eso. Otra cosa es que el código de JavaScript de React DevTools tiene muchas funciones importantes para calcular las diferencias en los árboles y generar IDs, esas no están expuestas públicamente. Entonces, ¿qué hicimos? Hicimos un fork de las React DevTools. Tengo una rama y un PR en borrador. He jugado con algunos de los internos de las React DevTools y eliminé un montón de código que no necesitábamos para nuestro caso de uso para intentar reducir ese paquete de $150K. Y encima de eso, todo esto está sucediendo durante el procesamiento en segundo plano. Pero, ¿qué pasa cuando estás depurando la grabación desde nuestra interfaz de usuario? Vamos a tener que tener React en la página en el navegador PaaS para que la interfaz de usuario pueda decir, como, qué son
7. Depuración de la Grabación y React
Pero es la grabación. Aún no existe. Por lo tanto, también inyectamos ese mismo paquete desde nuestro cliente en la grabación de PaaS para que podamos solicitar las props. En las aplicaciones de producción, los nombres de las funciones están minimizados porque todos se han reducido. A través del poder del viaje en el tiempo, podemos decir dónde se definió este componente, cuál era el nombre original del archivo, cuál era el nombre original real del componente, y podemos reescribir todos los nombres de los componentos a sus versiones originales, incluso si hiciste una grabación de una aplicación de producción. También hemos construido un salto al código, donde sabemos que has hecho clic o presionado una tecla en la aplicación. Podemos averiguar qué prop de React on click o on key press se ejecutó en respuesta y saltarte a esa línea de código en ese momento para que puedas comenzar a depurar. También hemos construido el equivalente de Redux DevTools, que extrae los tipos de acción, te muestra la lista de las acciones, el estado y la diferencia, y tenemos una serie de otras características en progreso.
las props para este componente. Pero es la grabación. Aún no existe. Entonces, en realidad también inyectamos ese mismo paquete desde nuestro lado del cliente en la grabación de PaaS para que podamos pedir las props. Te dije que esto era complicado. Entonces, eso nos ha dado el equivalente de la extensión React DevTools. Tenemos las operaciones y mientras estás depurando la grabación en diferentes puntos en el tiempo, podemos mostrarte cómo se veía el árbol de componentes. ¿Y si podemos hacerlo mejor? Estoy casi sin tiempo, irónicamente, así que voy rápido. En las aplicaciones de producción, los nombres de las funciones están minimizados porque todos se han reducido. A través del poder del viaje en el tiempo, podemos decir dónde se definió este componente, cuál era el nombre original del archivo, cuál era el nombre original real del componente, y podemos reescribir todos los nombres de los componentes a sus versiones originales, incluso si hiciste una grabación de una aplicación de producción.
Entonces, ¿cómo se ve esto aproximadamente? Esta es una versión muy reducida de la parte superior de nuestra rutina. Entonces, obtenemos esos objetos de anotación. Ahora sabemos en qué puntos en el tiempo nos importa. Evaluamos el código en cada punto para inyectar las herramientas de desarrollo de React y obtener las operaciones de data. Reprocesamos eso para averiguar los nombres originales de los componentes, reescribimos las operaciones de data con los nuevos nombres de los componentes y los guardamos para más tarde. Y cuando vas a debug una grabación, ahora tenemos las operaciones de data, y podemos mostrarte el árbol de componentes tal como existía en cualquier punto durante la grabación. El código para esto es semi-abierta. Vive en nuestro repositorio de back-end propietario, pero no tiene nada de especial. Son solo llamadas a nuestra API pública. Así que en realidad he copiado y pegado todas las 2,500 líneas de la rutina de post-procesamiento de back-end. Está en ese repositorio. Está disponible. Puedes echarle un vistazo. Puedes ver todos los trucos sucios, estúpidos y feos que he tenido que escribir para hacer que esto funcione.
También tenemos algunas otras características, y estoy casi sin tiempo, así que voy rápido. He construido algo llamado salto al código, donde sabemos que has hecho clic o presionado una tecla en la aplicación. Podemos averiguar qué prop de React on click o on key press se ejecutó en respuesta y saltarte a esa línea de código en ese momento para que puedas comenzar a depurar. Sé que si presiono este botón, algo explotó. Te acerca a donde probablemente ocurrió eso. También hemos construido el equivalente de Redux DevTools, que extrae los tipos de acción, te muestra la lista de las acciones, el estado y la diferencia, y tenemos una serie de otras características en progreso. Uno de mis compañeros de equipo es Brian Vaughn, quien construyó la mayoría de la interfaz de usuario de la extensión React DevTools, y ahora trabaja para Replay.
Reconstrucción de React DevTools y Preguntas y Respuestas
Estamos reconstruyendo React DevTools para un mejor rendimiento. Tenemos una característica de prueba de concepto para rastrear las llamadas setState y los tiempos de rendimiento para los envíos de Redux. También planeamos agregar pilas de componentes de React, línea de tiempo de commits y soporte para Source Maps. Consulta nuestro blog para obtener más información y no dudes en hacer preguntas. Prueba Replay para una depuración más sencilla de las aplicaciones de React. Sin embargo, Replay para React Native no está planeado por el momento.
En realidad estamos reconstruyendo nuestra integración de React DevTools. Es más rápido y más eficiente. Tenemos una característica de prueba de concepto que te muestra una lista de cada vez que tu aplicación llamó a setState en absoluto, y puedes saltar a ese código. Hice una prueba de concepto que desglosa los tiempos de performance para los envíos de Redux, y tenemos muchas otras características que queremos construir en el futuro.
Pilas de componentes de React, para ver cómo era el árbol en un punto en el tiempo en el código, línea de tiempo de commits y cambio de props anterior y siguiente. Último punto, realmente rápido, React no se envía con Source Maps. Si estás depurando, quieres Source Maps, para que veas el código original. Hace cinco meses, presenté un PR para modificar el pipeline de construcción de React para generar Source Maps. Lamentablemente, esto aún no se ha fusionado. Así que retroporté los cambios a las versiones anteriores de React y creé los Source Maps que habrían existido para 18.2, 18.1, y 17. Ahora tenemos un paquete de plug-in para tus build tools que reescribirá esos mientras construyes tu aplicación.
Bueno, eso es mucha información. Gracias por seguir conmigo. Tengo enlaces a estos. Tendré estas diapositivas en mi blog en blog.isquaredsoftware.com o por favor ven y haz preguntas. Espero que esto haya sido útil e interesante. Por favor, echa un vistazo a Replay. Hará que tu depuración sea mucho más sencilla y fácil de trabajar. Y espero que esto haga que tus aplicaciones de React sean más fáciles de debug. Muy bien, ahora hay muchas preguntas que han entrado. Este fue un tema candente. Realmente, realmente emocionante. También me encanta especialmente cuando tengo la oportunidad de aprender sobre una nueva herramienta que quiero usar o quiero intentar incorporar en mis flujos de trabajo de desarrollador. Voy a probar Replay. Ahora definitivamente voy a ser… Tienes el no tan sutil plug corporativo. Hey… hay que pagar las cuentas, hay que pagar las cuentas. Muy bien, así que la primera pregunta… Ahora, es gracioso porque dijiste que Replay fue construido y fue construido en el navegador de Firefox. La primera es… y tengo curiosidad por saber si esto es posible. ¿Replay para React Native? No en un futuro próximo. Así que, tenemos un conjunto de ingenieros de navegador C++ muy, muy inteligentes.
Replay: Precios, Objetivos y Estabilidad del Sistema
Las bifurcaciones son públicas y Firefox es estable para todas las plataformas. Chrome para Linux está grabando bien, pero aún necesita algo de trabajo en la interfaz de usuario. Chrome para Mac y Windows está en una etapa alfa temprana. Replay es gratuito para individuos y desarrolladores de código abierto, con un pequeño modelo de precios para empresas. El objetivo a largo plazo es que Replay funcione sin conexión y en modo de grabación permanente. Sin embargo, hay algunas dependencias de ciertos aspectos internos de React.
Las bifurcaciones son públicas. Puedes ver el código si quieres, pero son como cinco o seis mil líneas adicionales de código C++ y cambios en JavaScript por navegador para habilitar la captura de toda esta información. Así que, Firefox es estable para todas las plataformas. Chrome para Linux graba bien. Aún necesita algo de trabajo en la interfaz de usuario. Chrome para Mac y Windows está en una etapa alfa temprana. También tenemos una versión alfa de Node. Lo he usado para grabar y debug algunas pruebas de jest con el tiempo. Ahora el objetivo es llevar las bifurcaciones de Chrome a la paridad. Cambiar para hacer de ese el navegador principal. Luego enfocarse en Node. Podríamos hacer React Native algún día, pero esto es como varios años más adelante. Está muy abajo en la lista de prioridades, pero eso tiene sentido, especialmente cuando piensas en lo que los usuarios están utilizando.
Algunas personas están emocionadas de probar Replay. Preguntan si Replay es gratuito o si hay un modelo de precios. Replay es gratuito para individuos y desarrolladores de código abierto. Nos encantaría que más proyectos de código abierto adoptaran Replay como parte de su flujo de problemas. Todos preguntan, ¿puedes adjuntar un sandbox de código o un repositorio de GitHub que demuestre el problema? Tener una repetición del problema donde puedes simplemente abrirlo e inmediatamente debug, sin procesos de configuración ni nada. Hablando con mi sombrero de mantenedor de código abierto, lo hace mucho más fácil. Hay un pequeño modelo de precios por empresa para los desarrolladores, pero somos muy flexibles en eso. Me encanta eso. La razón por la que tuve que desencadenar ese aplauso es que siempre me encanta cuando las empresas realmente apoyan a la community de código abierto y a Replay.
Supongo que como es un navegador, ¿funciona sin conexión y en las instalaciones también? Sí, nuestros navegadores de grabación son realmente Firefox y Chrome solo con piezas adicionales incorporadas. Las cosas de grabación solo se activan una vez que realmente presionas el botón. Tenemos algunos objetivos hipotéticos a largo plazo de que algún día podría estar en modo de grabación permanente, algo así como un juego de video. Ves algo que sucedió que fue interesante, ¿presionas el botón de guardar resaltado? Eso también está a unos años de distancia, pero ahí es donde nos gustaría llegar. No, eso es interesante, especialmente considerando el hecho de que la mayoría de nosotros, tenemos como el navegador que usamos, o la forma en que usamos nuestro navegador para el uso diario general, y luego la forma en que usamos nuestro navegador para trabajar en nuestras aplicaciones y será interesante ver cómo Replay podría convertirse en un navegador solo para desarrolladores, ¿verdad? Ese es nuestro objetivo sin bromas. Bueno saberlo y luego la siguiente, creo que en realidad la pasé por alto, por la siguiente, lo siento, las preguntas se están moviendo, es sobre la fragilidad del sistema. Entonces, considerando que tienes como bastante, por falta de un término mejor, hacks en marcha. Sí. ¿Cómo ves la estabilidad a largo plazo de Replay? Definitivamente hay algunas partes donde las características que he construido dependen de ciertos aspectos internos de React.
Panel de Renderizado de React y Depuración de Viaje en el Tiempo
El panel de renderizado de React depende de la función central scheduleUpdateOnFiber. Las versiones de desarrollo de React funcionan con nuestro protocolo, pero las versiones de producción carecen de mapas de origen. Queremos tener conversaciones con el equipo de React para mejorar las herramientas. Replay graba las interacciones del navegador con el sistema operativo, permitiendo la depuración de viaje en el tiempo. Es una hazaña de ingeniería compleja.
La cosa del panel de renderizado de React de la que hablé depende específicamente del hecho de que cada vez que llamas setState en cualquier forma, useReducer, useState, cualquier otra cosa, siempre pasa por una función central dentro de React llamada scheduleUpdateOnFiber. Y con la forma en que funciona nuestro protocolo, puedo encontrar una función con ese nombre preguntándole a nuestro protocolo al respecto. Pero eso solo funciona con las versiones de desarrollo de React, especialmente porque las versiones de producción aún no tienen mapas de origen. Pero descubrí que las versiones de producción de React, la forma en que se minimiza, siempre hay un código de error numérico de paréntesis 185 en esa función. Así que si busco en el código fuente de React el paréntesis 185, encuentro el correcto... Ves por qué quería el mapa de origen. Esto suena doloroso.
Lo es. Así que no es sostenible. No es la forma en que me gustaría hacer las cosas, pero parte de ello es como, ¿puedo hacer que funcione ahora mismo? Y estábamos tratando de tener más conversaciones con el equipo de React. De hecho, hay un miembro justo allí abajo. Queremos tener más conversaciones sobre, ya sabes, si pudieras exponer un par de callbacks adicionales o algo así, entonces podríamos construir características adicionales útiles de una manera estable. Sí. Esperemos que funcione porque creo que tener no solo a React como un ecosistema, sino tener un ecosistema de herramientas y mejores herramientas a su alrededor, hará nuestras vidas mucho más fáciles.
Muy bien. Solo tenemos tiempo para una pregunta más. Las preguntas se están moviendo. Así que gracias por votar las preguntas que realmente te gustan. Alguien dice que está súper confundido acerca del hecho de que necesita un BE, creo que significa motor de navegador en este escenario, funcionando en una nube. ¿No podría simplemente funcionar en el complemento del navegador? Lo que Replay graba es el navegador hablando con el sistema operativo. Cada vez que el navegador abre un socket de red, recibe un paquete, hace una llamada a math random, todas las llamadas al sistema operativo son las que se graban. Como ejemplo, si haces un juego de tic-tac-toe con un generador de números aleatorios, y siembras el generador de números aleatorios, para que siempre produzca los mismos números cada vez. Puedes predecir cómo sucederá el juego de tic-tac-toe. Y de la misma manera, porque grabamos todas las entradas al navegador mientras lo estabas usando, más tarde, podemos iniciar el navegador en la nube, alimentarlo con esas entradas, y luego ejecutarlo por adelantado y como que pausarlo en muchos puntos en el tiempo. Y cuando dices, quiero saltar a los 17.5 segundos, encuentra una copia pausada del navegador, bifurca el proceso en Linux, y lo ejecuta por adelantado otro medio segundo. Suena a magia. Lo es. Es mucha ingeniería muy, muy inteligente. No soy lo suficientemente inteligente para haberlo hecho. Solo tengo que usarlo.
Discusión del Orador y Panel
Hay muchas más preguntas, y el orador estará en la sala de discusión y luego en un panel en el escenario principal. Aplaudamos una vez más por él.
Eso es increíble. Mira, hay muchas más preguntas, y estoy seguro de que las personas, podríamos pasar todo el día preguntando sobre esto. Pero sé que estarás en la sala de discusión de los oradores. ¿Es justo después de esto? Creo que estoy en la sala de discusión. Después de la sala de los oradores. La sala de los oradores justo después de esto. Y luego tengo que correr a un panel en el escenario principal. Y sí. Estás en alta demanda. Alta demanda. Pero aplaudamos una vez más por él. Muchas gracias.
Comments