Cómo Hackeé React Native DevTools (Y Construí un Framework de Plugins)

Hola, mi nombre es Simon, y estoy aquí para hablar sobre cómo creé un marco de trabajo de plugins personalizado para React Native DevTools que puedes instalar desde NPM y usar en tu trabajo diario para cargar los plugins personalizados, como, por ejemplo, Tasked y Query DevTools, para que puedas usarlos dentro de React Native DevTools. Básicamente no quiero anunciar la herramienta. Quiero mostrarte cómo la creé, qué se necesitó para hacerla funcionar. Así que antes de comenzar, déjame describir por qué necesitamos cosas como esta.

Así que en los viejos tiempos, existía Flipper, que era básicamente una herramienta de desarrollo diferente que podías usar para, bueno, trabajar con tus aplicaciones de React Native. Flipper era genial porque nos permitía construir plugins personalizados y cargarlos dentro de Flipper, así que luego podíamos, por ejemplo, tener Redux DevTools disponible para ser usado en el trabajo diario. El problema es que Flipper no era genial en cuanto a estabilidad, y había algunos problemas con, por ejemplo, la conexión se perdía silenciosamente entre Flipper y el dispositivo.

Así que probablemente por eso, Flipper fue anunciado como obsoleto. Así que desde hace algún tiempo, no podemos usar Flipper más porque, en primer lugar, está obsoleto, y en segundo lugar, el código necesario para comunicarse entre el dispositivo y Flipper ha desaparecido de React Native. Así que efectivamente, Flipper está muerto ahora. Tenemos React Native DevTools, que son geniales, que son estables, que ofrecen, bueno, una experiencia super para los desarrolladores, pero no podemos usar ningún plugin. No hay soporte para ellos todavía. El trabajo en ellos está en curso, pero básicamente no estamos allí todavía.

Así que necesitamos alguna solución temporal que podamos usar por este tiempo donde no hay soporte oficial. Y si no tenemos ningún plugin, entonces podemos decir que estamos de vuelta en la Edad Oscura porque necesitamos hacer console log de todo, terminando con una gran cantidad de logs, y luego necesitamos inspeccionarlos, ir uno por uno, buscando cualquier problema. Y debes admitir que no es la mejor experiencia para el desarrollador. Así que es exactamente por eso que creé Rosanoid, el marco de trabajo de plugins personalizado para React Native DevTools que puedes usar para crear plugins y cargar plugins en las DevTools mencionadas anteriormente.

Mi nombre es Szymon Chmal, y soy un experto en React Native en Callstack. Soy desarrollador web de corazón, pero recientemente me he enfocado más en el desarrollo multiplataforma, en el desarrollo móvil con React Native. Me encanta compartir conocimientos a través de conferencias, encuentros, o simplemente escribiendo artículos, por ejemplo. Estoy contribuyendo a las herramientas de desarrollo en Callstack Incubator. Este es un grupo especial de personas en Callstack que básicamente... Bueno, estamos jugando con la tecnología y estamos tratando de avanzar tanto como sea posible. Y soy el creador de Rosanoid y del recientemente anunciado React Native Harness, que es un nuevo marco de pruebas para React Native. Y estoy programando desde Toruń, en Polonia, así que la ciudad en sí es conocida por el pan de jengibre y ser el hogar de Nicolás Copérnico en el pasado.

Ahora, antes de sumergirnos en el código, necesitamos entender cuáles son las limitaciones de nuestro plugin del marco de trabajo de DevTools personalizado, el marco de trabajo de plugin personalizado para DevTools. En primer lugar, no queremos hacer un fork de nada porque no tenemos la capacidad de mantener ningún fork y, por ejemplo, sincronizar los cambios entre el repositorio original y nuestro fork. No queremos bloquear a los usuarios de usar React Native DevTools si nuestro marco de trabajo personalizado falla al cargar. Así que nuestros cambios en la infraestructura deben ser mínimos. Si algún plugin falla, todo el sistema, toda la interfaz de usuario de DevTools debería seguir funcionando correctamente. Nuevamente, para no bloquear a los usuarios de desarrollar.

Necesitamos implementar el plugin de una manera que las personas puedan usar React para implementar las interfaces de usuario de los plugins porque son desarrolladores de React Native, así que React es, bueno, como, la cosa que usan todos los días. Y por último, pero no menos importante, deberíamos reutilizar el enlace de comunicación existente entre el dispositivo y React Native DevTools. ¿Por qué? Aprenderemos sobre las ventajas de este enfoque en un minuto. Así que comencemos con algunos hechos sobre React Native DevTools. Así que podrías pensar que React Native DevTools es básicamente una aplicación nativa que se ejecuta en tu sistema operativo, digamos. No es cierto. Es básicamente una aplicación web que se abre en Chrome con un encabezado oculto, con una barra de herramientas oculta para que no veamos la URL. Pero puedes acceder a la URL, y entonces verás que es básicamente un servidor local que aloja la interfaz de usuario bajo la ruta del front-end del depurador.

La interfaz de usuario, el código de la misma, está disponible en GitHub, por lo que siempre puedes ir al repositorio de GitHub para inspeccionar el código. Y el código empaquetado también se distribuye a través del paquete npm y luego se carga en nuestro sitio a través de Metro. Y Metro es el empaquetador personalizado utilizado por React Native. Así que básicamente hay un middleware personalizado incrustado en Metro, que toma el paquete npm que acabo de mencionar, lo lee y luego lo sirve al usuario a pedido.

Y cuando se trata del protocolo de DevTools, el enlace de comunicación, queremos reutilizar el existente que utiliza React, perdón, que utiliza el protocolo de Chrome DevTools. ¿Por qué? Porque, por ejemplo, si inyectamos nuestra comunicación, nuestros mensajes en este enlace, entonces podremos depurar dos dispositivos al mismo tiempo, lo cual no es realmente sencillo si creamos un enlace personalizado. Y esto es algo con lo que muchos, muchos DevTools personalizados luchan, porque no hay una manera simple de diferenciar entre dispositivos. Es posible para React Native para sus internos lograr eso, pero no es posible o es difícil desde el lado del usuario lograr lo mismo.

Así que nuestro plan es el siguiente. Primero necesitamos forzar a React Native a lanzar la URL personalizada, para que podamos servir una interfaz de usuario personalizada. Y luego, si logramos eso, podemos inyectar algo de código JavaScript personalizado, y ese es nuestro plan para el paso dos. Y luego dentro de este código personalizado inyectado en la interfaz de usuario de DevTools, queremos usar la API existente en los DevTools para crear un nuevo panel y mostrar un iframe en él. Y por último, pero no menos importante, queremos aprovechar la capa de comunicación existente y enviar mensajes de ida y vuelta entre el dispositivo y la interfaz de usuario de DevTools. En cuanto a la URL, necesitamos encontrar el lugar donde se crea esta URL.

Así que me adentro en el código y veo esta función getDevToolsFrontEndURL, que existe en el React Native dev.middleware.ut.getDevToolsFrontEndURL. Y como puedes ver, hay esta constante de URL de la aplicación, que incluye nuestro frontend del debugger. Queremos cambiar del frontend del debugger a algún texto personalizado. En mi caso, será Rosenite. Y como puedes ver, esto es básicamente un módulo y esta función se exporta desde este módulo.

Así que significa que podemos acceder a ella desde nuestro código personalizado y hacer algo con ella. Y el plan es usar monkey patching para básicamente envolver la función con nuestra función personalizada y reemplazar el frontend del debugger con Rosenite. Así que esto es un hack. Y bueno, este es el único hack necesario para que todo funcione.

Entonces, ¿cómo funciona? Bueno, primero necesitamos requerir el módulo por ruta absoluta. Así que básicamente no estaremos limitados por ninguna regla de encapsulación.

Así que lo llamamos primero con todos los argumentos pasados por el llamador. Y luego reemplazamos el segmento del frontend del debugger con nuestro segmento personalizado de Rosenite. Luego, lo siguiente que necesitamos hacer es básicamente inyectar el middleware personalizado. Así que podremos servir nuestra UI de DevTools desde una URL diferente básicamente. Y esto es posible porque Metro acepta una propiedad de configuración llamada enhanced middleware. Y con esta propiedad, básicamente puedes inyectar un middleware personalizado, que en nuestro caso servirá el HTML estático y JavaScript más algunas cosas dinámicas en el futuro.

Pero tendremos el control total sobre ello. Así que después de hacer esto, después de crear el middleware, después de aplicar el monkey patch, cuando abramos React Native DevTools, veremos la URL personalizada siendo utilizada y los DevTools en sí funcionarán perfectamente, lo cual es genial y lo que hace posible pasar a lo siguiente. Así que inyectando un script personalizado en el HTML. Así que sí, esta es una aplicación web básica. Hay un archivo HTML, que es un punto de entrada, y ahí puedes ver que hay una etiqueta de script incluyendo el punto de entrada, pero esta vez en forma de JavaScript. Así que lo que queremos lograr es básicamente una segunda etiqueta de script, que cargará nuestro punto de entrada de JavaScript personalizado.

Y no reemplazaremos todo con nuestro archivo HTML personalizado. Lo siento, no reemplazaremos todo. ¿Por qué? Porque se puede decir que en el futuro, alguna parte de ello será cambiada. Y eso es exactamente lo que sucedió cuando React Native 0.81 fue lanzado. Y los usuarios comenzaron a crear problemas en el repositorio de Rosemary mostrando esto. Lo que sucedió es básicamente que algunas etiquetas de script, o lo siento, etiquetas de enlace cargando archivos CSS fueron añadidas y toda la estructura CSS fue cambiada. Así que mientras servía el archivo antiguo, pero con mi cambio aplicado, técnicamente removí las etiquetas de enlace y eso causó que la UI se viera así. Así que queremos ser mejores. Queremos aplicar este cambio solo a la última versión del archivo.

Además, queremos hacerlo de una manera que minimice la posibilidad de que tales cosas sucedan nuevamente en el futuro. La nueva idea, el nuevo enfoque es cargar el archivo en tiempo de ejecución cuando el archivo es solicitado por Chrome, y luego agregar la etiqueta de script personalizada después de algún elemento que se sabe que siempre está presente en el archivo HTML. Y en mi caso, estoy usando la etiqueta body porque siempre hay una etiqueta body. Y está bien agregar una etiqueta de script justo después del body. Y eso es exactamente lo que está sucediendo allí.

Luego necesitamos obtener acceso a la DevTools UI API. Así que necesitamos poder crear algunos paneles, algunos paneles personalizados, algunas pestañas personalizadas, y luego el iframe. Así que podremos mostrar cualquier UI que queramos. Así que si nos sumergimos en algún código que ha sido empaquetado y publicado como paquete npm, verás que hay declaraciones de importación y exportación, lo cual es importante porque normalmente cuando empaquetas tu aplicación web, terminas con un sistema de módulos reemplazado por, por ejemplo, webpack o un vid. Y en tal caso, no puedes realmente, o es difícil importar tales módulos en tu código personalizado. Pero con declaraciones de importación y exportación, básicamente podemos copiar el código, copiar las declaraciones de importación en nuestro JavaScript personalizado, y se resolverán en tiempo de ejecución así de simple. Así que obtendremos acceso a todas las clases exportadas de los módulos desde nuestro código JavaScript personalizado.

Así que después de mucho tiempo, encontré que existe esta vista de inspector, que es responsable básicamente de contener todas las pestañas o los paneles y mostrarlos. Así que en esta clase, encontré dos métodos. Uno de ellos es súper importante para mí porque me permite agregar paneles personalizados. Así que pasando una instancia de vista. Así que luego comencé a buscar una vista en algún lugar del código, y encontré que puedes crear una vista personalizada extendiendo una vista simple, que no hace nada bajo el capó. Así que creo una vista de plugin, que básicamente crea un iframe, y este iframe se muestra en los contenidos de una vista. También añadí algunos oyentes de eventos. Así que hablaremos de ello en detalle en un minuto o dos. Pero básicamente para proporcionar el enlace de comunicación entre el plugin en sí y el host. Así que DevTools UI, mi código personalizado. Así que el plugin podrá comunicarse con el dispositivo a través del host. Y después de eso, después de todos esos cambios, podemos ver esta hermosa pantalla.

Por supuesto, no está incluido en el DevTools todavía. Es básicamente una URL remota mostrada como un panel dentro de un iframe. Pero es algo. A partir de este punto, técnicamente podemos mostrar cualquier cosa que queramos porque los iframes son básicamente instancias de Chrome, pero incrustadas en diferentes instancias de Chrome, ¿verdad? Así que ahora podemos empezar a trabajar en plugins. Y necesitamos entender que los plugins se componen de dos partes. Una parte está trabajando en React Native y una parte está trabajando en DevTools UI. Así que la parte que trabaja en el lado de React Native no necesita ser empaquetada porque Metro se encargará de eso por nosotros. Solo necesitamos cambiar de TypeScript a JavaScript, pero eso es fácilmente realizable a través del compilador de TypeScript.

Sin embargo, en DevTools UI, el estado de las cosas es diferente allí. Necesitamos empaquetar el código con algún empaquetador como Vid. Terminaremos con HTML y JavaScript que se pueden cargar en Chrome sin ningún problema. Y por ejemplo, Vid es una herramienta perfecta para eso porque Vid soporta cosas como Tailwind, así que las personas que crean la UI para sus plugins pueden usar Tailwind, lo cual es genial. Y luego la última parte que falta es el puente, la forma de comunicarse desde el lado del dispositivo con DevTools UI y viceversa desde DevTools UI al dispositivo. Y el problema es que este puente necesita funcionar en ambos lados donde el entorno difiere significativamente. Pero antes de sumergirnos en las diferencias exactas, veamos la interfaz.

Así que el cliente es bastante simple. Tiene métodos para enviar y listar mensajes. Y hay un hook personalizado que devuelve null por defecto, pero luego cuando se establece la conexión entre React Native DevTools y el dispositivo, devolverá un cliente en su lugar. Y ahora volviendo al problema del isomorfismo. Así que necesitamos usar lógica diferente para enviar mensajes y para escucharlos en el lado del dispositivo y en el lado de DevTools UI. Así que lo que hice es básicamente inyectar un global personalizado cuando estoy construyendo una UI de plugin, así que luego en este puente de plugin, puedo verificar si este global está presente. Si es así, entonces sé que estoy trabajando en el lado de DevTools UI y puedo usar lógica diferente para enviar mensajes. Si no hay tal global, sé que estoy trabajando en el lado de React Native y quiero, lo siento, y puedo usar los enlaces, los métodos globales proporcionados por el entorno de React Native. Por el contrario, cuando estoy en el lado de DevTools UI, necesito usar la API postMessage para que podamos pasar mensajes del iframe al host y el host, nuestro JavaScript personalizado, escuchará cualquier mensaje que venga del plugin y los reenviará al dispositivo, lo que básicamente establecerá un enlace entre ambas partes.

Y ahora es el momento de ver qué es posible lograr con tal configuración para plugins e inyectar paneles personalizados y básicamente todas las cosas que hicimos. Así que este es el plugin de actividad de red, que es un plugin oficial para Resonight y como puedes ver, puedes inspeccionar tu actividad de red. Puedes, por ejemplo, inspeccionar cabeceras. Puedes inspeccionar respuestas y si una respuesta es de tipo JSON, entonces puedes interactuar con el árbol JSON. Puedes colapsar ciertos subobjetos o expandirlos. Lo mismo se aplica a los cuerpos de las solicitudes.

Todo el plugin, el plugin de actividad de red, soporta HTTP, web socket y eventos del lado del servidor además te permite filtrar cosas, por ejemplo, por ruta. Así que terminarás con solo una pequeña lista de solicitudes. Así que sí, todo esto hizo posible crear Resonight, que es un framework para plugins personalizados básicamente para Reactivity DevTools. Resonight te permite construir frameworks. Se asegurará de que se construyan correctamente para que puedas cargarlos en Reactivity DevTools. Si instalas cualquier plugin, Resonight lo descubrirá automáticamente y lo ejecutará.

Funciona con prácticamente cualquier combinación posible al desarrollar React Native. Así que funciona con React Native CLI además funciona con Expo, Metro y Reapak y viene con un conjunto de plugins oficiales que puedes usar en tu trabajo diario. Lo siento. Si quieres saber más sobre Resonight, siempre puedes escanear el código QR visible ahora mismo en la pantalla y te llevará a la página de documentación de Resonight donde encontrarás, por ejemplo, una guía de inicio rápido. Así podrás instalar Resonight con un solo comando en cuestión de segundos. En caso de que tengas más preguntas sobre Resonight, sobre cualquier cosa que dije durante esta presentación, no dudes en contactarme. Puedes contactarme en X, puedes contactarme en LinkedIn, puedes contactarme en el canal de Discord para Resonight, que está presente en el servidor de Discord de ColdStack, al que puedes unirte a través del enlace presente en el sitio de documentación de Resonight. Así que eso es todo. Gracias por estar conmigo y espero que hayas aprendido algo interesante hoy. Nos vemos.