Arquitectura de Sistemas React Confiables en Entornos No Confiables

Hola a todos. Bienvenidos al React Summit 2026. Espero que todos estén pasando un buen rato aquí. Gracias por unirse a mi charla y estoy realmente emocionado por ello. Hoy, hablaremos sobre la arquitectura de sistemas React confiables en entornos poco fiables. Así que comencemos. ¿Alguna vez han visto una pantalla que parece estar bien mientras el sistema está en un estado malo o incorrecto? Estoy seguro. Como muchos de ustedes han visto esto, especialmente trabajando con sistemas React, como un spinner que nunca se detiene. Un mensaje guardado después de una solicitud fallida. Datos obsoletos en la siguiente página. Errores que no se bloquean. Pero el sistema bajo el capó no está funcionando correctamente en un mal estado. Así que hoy estamos explorando cómo solucionar esto con arquitectura y no más reintentos o formas improvisadas y chapuceras. Así que vamos.

Bien. Sobre mí, soy Rajnikadia. Soy ingeniero de software en Hinge Health y diseño y construyo sistemas confiables para dispositivos conectados en entornos regulados. Mi enfoque es la arquitectura y la confiabilidad para aplicaciones móviles, wearables y hardware BLE en programas activos de atención al paciente. Aquí están mis enlaces de redes sociales, así que siéntanse libres de seguirme o conectarse conmigo. Además, estoy trabajando en la construcción de una plataforma de validación BLE, que es de código abierto. Esto ayuda a construir un marco de prueba BLE impulsado por perfiles. Así que si no tienen un dispositivo físico pueden usar esto para simular un dispositivo y es muy flexible.

Así que pruébenlo. Bien. Entonces, el problema principal. React es predecible. El mundo exterior no lo es. Su UI parece estar bien y bajo el capó está funcionando de manera diferente. Su UI asume que todo debería estar en orden y en secuencia.

Pero en realidad, puede ser diferente. Como cuando la API falla o el dispositivo conectado pierde la conexión intermitentemente. Así que la situación del mundo real es totalmente diferente de lo que esperamos.

¿Por qué explota la complejidad asíncrona? Así que puede haber muchas razones. Como muchas cosas sucediendo al mismo tiempo. Como cuando interactúas con la UI. Hay una llamada a la API. Estás conectando con un dispositivo Bluetooth o un dispositivo conectado y este se desconecta en medio. Hay un reintento. Muchas cosas pueden impactar el flujo de tu aplicación.

Por ejemplo, guardas un botón de clic dos o tres veces y no tienes un throttling. Así que la solicitud de API anterior o la solicitud de clic está pendiente y sigues saturando ese flujo. El segundo es que nadie posee el plan. A lo que me refiero con eso es que hay múltiples efectos de UI y cada efecto de UI tiene su propio ciclo de vida. Así que uno no sabe cómo está el otro o cuál es la secuencia entre ellos a menos que usemos una forma improvisada como usar un user ref.

Así que un efecto de usuario múltiple es un problema y nadie los coordina. Así que cada vez que notes que hay un efecto de usuario múltiple necesitas solucionar ese problema. El tercero es que el estado vive en demasiados lugares. Como cuando usas useState, useRef, o como una instancia singleton de estado y no hay un enlace entre ellos. Así que es difícil depurar o incluso rastrear cualquier problema como un spinner o error o todo esto. Como cuál es el problema cuando vemos algo en la UI. Es difícil predecir qué estado está derivando esta UI en particular.

Fallos de fiabilidad en el mundo real. Así que estos son los casos como un dispositivo estaba conectado, por qué la sesión está muerta. Así que por ejemplo, en la pantalla dices ok el dispositivo está conectado como una UI de marca de verificación verde. Pero en realidad, está haciendo como un reintento o la conexión real ya se ha caído. En el caso de la API, es como algo similar sucede. Puede decir ok estos son los datos en vivo pero en realidad la API falló o está en un estado de error. Así que no hay sincronización entre la UI y el estado real del sistema. Y tormenta de reintentos después de una breve desconexión.

Así que por ejemplo, hay 50 solicitudes de reintento en 10 segundos. Así que podría parecer bien en la UI pero bajo el capó está saturando el backend con múltiples reintentos sin ninguna conexión con tu UI. Así que eso es una señal de que algo no va bien respecto a la gestión del estado. Cierre del estado. Así que la UI muestra datos obsoletos. Así que de nuevo, dije como solicitaste o te conectaste al dispositivo y la UI dice ok estás conectado o está muerto. Pero podría estar mostrando los datos de la última sesión o del último estado obsoleto.

Otro ejemplo, como un fondo y un primer plano. Así que por ejemplo, si estás trabajando con una aplicación móvil o incluso para un navegador web, estás cambiando entre las pestañas, estás obteniendo un enfoque, perdiendo un enfoque. Y en el caso de una aplicación móvil, si tu programa en segundo plano digamos que estás trabajando en un dispositivo conectado. Así que cuando vienes al primer plano, intentas reconectar tu dispositivo. Así que aquí digamos que de alguna manera la aplicación está haciendo múltiples veces fondo primer plano. Así que en este, si no usamos como un sistema particular de gestión de estado, tu aplicación puede saturar sobre reintentar al estado, reintentar a los dispositivos conectados y eso puede tener como múltiples conexiones y solo una está activa pero el resto solo está reintentando. Lo cual puede poner tu aplicación así como tu dispositivo en un mal estado.

Actualización OTA interrumpida. Por ejemplo, estás trabajando con un dispositivo conectado y comienzas a actualizar el firmware en ese dispositivo. De alguna manera eso falló o se interrumpió debido a, digamos, una reconexión u otra razón, entonces la aplicación se queda atrapada en ese estado de limbo. Así que no hay sincronización entre la aplicación y una UI y el estado real.

Bien, otro problema clásico es el problema de la sopa de Booleanos. Así que creo que muchos de ustedes han visto esto. Así que cuando comenzamos una aplicación de React, tal vez como un principiante, comenzamos con un nuevo estado porque ya está adicto a usar.

Como tomamos un estado, establecemos el estado y hacemos set state, entonces repintará tu aplicación de React. Está bien para alguna aplicación pequeña. Pero a medida que tu aplicación crece, podrías sentir que hay tal vez 5, 10 o tal vez 50 use state que estás usando.

Podría funcionar correctamente, pero estoy seguro de que habrá problemas porque cuando tomas ese estado y necesitas actualizar el estado. Entonces, si hay 50 estados, en algún lugar, ya sea en un callback, como un callback de clic o en un use effect, estará llamando a set state algo, set state algo y todos están fuera de sincronización entre sí y esos estados también podrían estar en una dependencia de use effect. Así que las cosas pueden ser muy desordenadas, como que no sabemos qué estado se está actualizando cuándo y pondrá tu UI en un mal estado. Así que tal vez parezca que está funcionando, pero puede desencadenar un use effect adicional, puede desencadenar un efecto secundario de llamada externa adicional y no tienes ningún control sobre eso. Es muy difícil de depurar.

Así que, por ejemplo, aquí digamos que tenemos un estamos implementando una gestión de estado para la conexión Bluetooth. Así que podríamos tener variables como estados como is connected, is connecting, is scanning, así que retrying tiene un error o sincronizando con el backend. Así que si tenemos esto, entonces podrías tener imagen en use effect, estaremos actualizando algunos de ellos dependiendo de la conexión, dependiendo de los datos que obtenemos del backend y nuevamente actualizándolo. Así que el otro problema es que no sabemos qué UI queremos mostrar aquí. Por ejemplo, si está conectado y conectando, ambos pueden ser verdaderos y es trying puede ser verdadero. Así que técnicamente puede ser verdadero porque hay tres variables diferentes, tres estados diferentes y digamos que de alguna manera debido a como spam o cualquier otro flujo de la aplicación, tu aplicación está en un estado donde todo esto es verdadero.

¿Qué UI se mostrará? Por ejemplo, si estás mostrando una UI particular basada en un use state particular, entonces todas estas tres UI serán verdaderas. Como tal vez marca de verificación o verde, entonces será confuso. Como el usuario podría pensar, está bien, ¿cómo es posible que todo esté en un estado? Así que básicamente la cosa es que el estado de la UI no puede derivarse de este múltiple use state individual. Así que esto es como un problema clásico de sopa de Booleanos y esto no es solo con el Booleano, puede ser como un entero o cualquier otro tipo primitivo.

Bien, entonces caos de dependencias de useEffect. Así que aquí, por ejemplo, tu aplicación está trabajando con dispositivos conectados a la red y digamos que primero estás obteniendo datos de una API y luego conectándote a tu dispositivo Bluetooth. Entonces digamos que sigues el mismo patrón de useState que vimos en la última diapositiva. Entonces, ¿qué puede pasar aquí? Como puedes ver en la diapositiva, por ejemplo, cuando el dispositivo BLE se conecta, puede desencadenar una actualización de estado. Bien, UI2 conectado. Llegas a un programa como el ciclo de vida de la aplicación. Puede intentar volver a intentar la API y también puede intentar reconectar tu estado BLE, dispositivos conectados BLE, y también puede desencadenar useEffect porque digamos que como parte del callback de respuesta estás actualizando estados y ese estado está en dependencia de useEffect. Así que esto puede desencadenar esto y una vez que va a esa dependencia, entonces entiendes que desencadenará muchas otras cosas. Como en ese useEffect, podrías tener una llamada de red o podrías tener una actualización a otro useState, otro setState, por lo que puede desencadenar otro useEffect. Y todo esto puede ser un desastre. Como incluso si es difícil depurar ese problema o depurar ese flujo, si pones un console log o cualquier rastreo en ese useEffect, entonces no sabes el momento porque cuando haces set update, desencadena un useEffect, desencadena callbacks, y sí, puedes ver alguna secuencia pero no siempre está garantizada. Y no hay un solo controlador, bien, después de esto, esto debería suceder, después de esto, esto debería suceder. Y también es más difícil de leer, mantener y también depurar. Así que básicamente, si hay múltiples fuentes asíncronas como esta y ningún coordinador, entonces te conviertes en un desastre.

Así que complejidad de estado oculta. Así que sabemos como un useRef, así que usamos ref para mantener el valor que no desencadenará el re-renderizado. Por ejemplo, digamos que quieres mostrar una notificación de toast solo una vez. Así que tal vez una forma hacky que harás es como simplemente tomar una variable useRef y una vez que se muestra en la pantalla, la configuras a true y la próxima vez simplemente verificarás, bien, es true, no lo muestres. Así que esto puede ayudar a mitigar, diría, como no quieres mostrar la máquina de toast múltiples veces para la misma instancia. Pero entonces esto es un hacky porque solo estás suprimiendo temporalmente el problema como, bien, una vez mostrado, no lo muestres, pero es posible que dependiendo de cómo estés actualizando ese useRef, podría mostrarse de nuevo o incluso mostrarse de nuevo en el momento equivocado, lo cual es como una pérdida. El segundo es un closure puede recordar valores antiguos de un final anterior. Así que por ejemplo, podrías haber notado que estás usando un useCallback y hay una dependencia. Y si haces clic o llamas a ese closure, es posible que ese valor particular sea antiguo, no está actualizado porque estás usando un useState o useRef dependiendo de cómo lo estés usando, puede apuntar a un valor antiguo. Así que también puede crear un problema funcional y problemas de UI. Nuestro tercero es el temporizador. Así que el temporizador puede seguir funcionando después de que hayas dejado la pantalla. Así que por ejemplo, no has limpiado tus temporizadores que desmontaste o incluso digamos que te desconectaste y no limpiaste eso, entonces ese temporizador particular seguirá desencadenándose o incluso después de que dejes esa página porque no está vinculado al estado de React, es como un tiempo de ejecución de JS, que desencadena ese set timer. Así que por ejemplo, digamos que hay una pantalla de inicio y tienes un temporizador, olvidaste limpiar ese temporizador. Así que seguirá disparándose incluso si te mueves a una pantalla diferente como una pantalla de configuración. El listener, similar a los temporizadores como estás suscrito a un evento de conexión de un dispositivo conectado como un dispositivo Bluetooth, si olvidas eliminar ese listener al desmontar, entonces seguirá siendo llamado.

Podría estar actualizando tu estado y esto puede llevar a una fuga de memoria. Así que está totalmente oculto y tu aplicación puede consumir más memoria y las cosas pueden empeorar si sigue acumulándose.

Lo último es la observabilidad. Así que DevTools solo muestra el estado de React, no la imagen completa. Así que lo que sea que pongas en un estado, como un estado de Redux o un estado local, puedes verlo en DevTool, pero no te dará la imagen completa de cómo funciona el flujo de tu aplicación. Porque hay múltiples fuentes asíncronas, hay múltiples use effect, es difícil. Incluso si pones un console log, no es fácil predecir o depurar un error particular usando DevTools.

Bien, entonces estado de UI imposible. Esto solo muestra cómo el estado de la UI puede ser diferente de la realidad actual. Así que, por ejemplo, tu UI está diciendo, bien, tu dispositivo está conectado, y la sesión está activa, y la señal es fuerte, como si la conexión fuera fuerte, pero en realidad, el dispositivo está desconectado, porque no usamos ningún flujo de gestión de estado particular aquí. No hay sincronización entre la realidad del sistema actual y la UI.

En segundo lugar, es como, digamos, si estás sincronizando, como si te estuvieras conectando con un buen dispositivo, o incluso obteniendo datos activamente, o enviando datos al backend, la UI dice, bien, todo está bien, está sincronizando, pero en realidad, no hay sesión activa, no está ocurriendo ninguna API. Podría detenerse debido a un error o reintento o algo.

Lo siguiente es como un estado de listo, como si todo estuviera listo, conectado, sincronizado, ahora está listo para operar en ese dispositivo conectado en particular, o ese panel de API, pero en realidad, está en progreso de hacer algo, como si estuviera actualizando un firmware, o incluso una solicitud de API activa está en curso. Así que nuevamente, discrepancias entre el estado de la UI y el estado real del sistema.

Para el otro caso, es como ideal, bien, todo está bien, no está pasando nada, es ideal, pero en realidad, solo está enviando spam al reintento. Así que, por ejemplo, te conectaste, todo está bien, y estás en estado sincronizado, y la UI dice, bien, todo bien, solo está esperando que presiones un botón de conectar, pero en realidad, está haciendo un reintento. Así que, debido a un use effect, catch, try, catch, y reintento, reconectar, tu aplicación está ocultamente haciendo esas cosas.

Entonces, por ejemplo, el problema con esto es que cuando haces clic en conectar, no se conectará, porque sigue intentando, y no hay sincronización entre la UI y el sistema. Así que, sin una única fuente de verdad, la UI puede mentir sin fallar. Entonces, aquí, el problema es que no estamos notificando al usuario que algo está saliendo mal, porque digamos que algo está yendo mal, estrellaremos la aplicación para que pueda recuperarse de la memoria o ayudarte a poner tu teléfono o sistema en un mal estado. Aquí, no estamos fallando ni notificando al usuario. Así que, en realidad, es una mala experiencia de usuario, porque el usuario sigue intentando, por qué no se conecta, por qué no se conecta, y bajo el capó, solo está reintentando, y no hay indicación o UI intuitiva que informe al usuario, está bien, estamos intentando o algo.

¿Por qué los reintentos solos fallan? Entonces, retry, quiero decir como si algo estuviera mal, intentas arreglarlo invisiblemente en el backend o en el fondo, diría yo. Entonces, reintentos desde, entonces, primero son reintentos desde, como una desconexión desencadena muchos reconectar. Entonces, por ejemplo, te conectas a un dispositivo y se desconecta. Entonces, digamos que pones como un try catch en esa conexión y falló, vuelves a llamar a conectar. Entonces, es como una llamada recurrente para conectar, desconectar, desconectar, conectar. Así que nadie coordina cómo funcionan las cosas. El problema es que te conectas, la UI dice conectar, pero está fallando, nuevamente conectando, fallando, conectando. Así que, si estás usando estados únicos como un nuevo estado, y solo dependiendo del Boolean, entonces, estará parpadeando un poco, desconectar, conectar, desconectar, conectar. Creo que como quien esté trabajando en un dispositivo Bluetooth podría haber enfrentado este problema, como lo difícil que es gestionar el estado entre las diferentes fases de conexión.

El segundo es trabajo duplicado. Como cuando reintentas o tocas un botón o como estilo de vida, como un programa en segundo plano, llamas al método de conectar solo para arreglar ese problema o problema de reintento. Entonces, el problema es que hay tres sitios de llamada diferentes para el conectar y es difícil rastrearlo a menos que pongas registros explícitos o logging allí, pero creo que es un mal patrón llamar a un método de conectar tres veces solo para arreglar el mismo problema de reintento. Veremos cómo podemos arreglarlo con la máquina de estados. Máquina de estados reintentos obsoletos. Entonces, por ejemplo, estás desconectado y presionas conectar. Digamos que presionas conectar tal vez múltiples veces. Tal vez el usuario está probando o tal vez hay un error, como un error lógico que desencadena como múltiples conexiones. Entonces, aquí lo que sucede es como una primera solicitud está en proceso y aún se coloca otra solicitud. Así que no hay verificación. Está bien, si la primera solicitud está en curso, entonces espera o termina eso y haz la solicitud nueva nuevamente. Así que la solicitud obsoleta sigue como antigua porque todavía está pendiente y acumulará la nueva solicitud. Así que crea un problema porque digamos que la primera solicitud se ejecutó, la segunda se ejecutará. Así que, innecesariamente habrá múltiples callbacks que pueden poner tu UI en un mal estado. Reintentos ciegos. Entonces, por ejemplo, para OTA o configurar una conexión Bluetooth y estás intentando en el momento equivocado.

Entonces, por ejemplo, cuando haces una actualización de firmware, tu aplicación necesita estar conectada a un dispositivo Bluetooth. Pero aquí, si no tienes gestión de estado, lo que sucederá es que la UI puede mostrar actualización de firmware incluso si está desconectado. Así que, de nuevo, hay un problema como una mala UX. El usuario hará clic en firmware asumiendo que está conectado, pero en realidad no lo está. Así que, es un reintento ciego sin verificar cuál es el estado actual del dispositivo.

Bien. Entonces, ¿quién decide qué sucede a continuación? Sin una capa de orquestación, todo es un agente libre. Así que, todos son libres.

Pueden lanzar actualizaciones, pueden llamar a otros callbacks, y no hay un intermediario que esté gestionando todos los estados y es realmente difícil gestionar ese tipo de sistema en particular. Bien. Así que, aquí ahora vamos a la solución. Entonces, cómo podemos construir una arquitectura determinista. Entonces, podemos hacer esto definiendo un estado exacto en el que tu aplicación puede estar. Así que, por ejemplo, tu página puede estar en un estado de carga, listo, error.

Si estás usando un dispositivo Bluetooth, puede ser como un estado de inicio, estado de verificación de permisos, escaneo, vinculación, conexión, y luego desconexión o estado de reintento. Así que hay un límite claro o una definición clara de cada estado aquí. El segundo es definir transiciones permitidas. Así que, lo que quiero decir con eso es necesitas definir, está bien, el usuario puede pasar de inicio a escaneo solamente. No pueden ir directamente de inicio a conexión porque no hay forma realmente práctica.

De la misma manera, si estás trabajando con la API necesitas definir como un primer paso un login, luego la obtención de la API, luego renderizar el perfil de usuario actual, y luego tal vez si hay un error, reintentar. Así que, hay un límite claro entre ellos y hay una transición clara y lo siguiente es el alcance async al estado. Así que, simplemente define como por ejemplo iniciar la llamada a la API cuando entres en carga y cancelar todo lo demás. Así que, aquí básicamente estás poniendo una fase de init y una de limpieza antes de ejecutar el estado real. Así que, por ejemplo, si entras en la fase de conexión quieres asegurarte de que el proceso de escaneo se detenga o se limpie. Si estás saliendo de ese estado de conexión quieres asegurarte de que cualquier cosa como cualquier registro particular o cualquier, por ejemplo, temporizadores que hayas configurado en esa conexión temporal quieres limpiarlo. Así que, esto asegurará que cuando transiciones entre el estado siempre se limpiará el estado anterior y no habrá problema de como una fuga de memoria o sugerencia de callback fantasma o actualización de UI.

Y el último es derivar la UI de los estados. Así que, aquí lo que quiero decir es que ahora hemos definido los estados. Así que, la UI como React UI solo mira el estado. No debería verificar usando ref individual o use state individual. Solo dice está bien cual sea tu estado solo dame el estado de la UI y lo mostraré. Así que, es muy determinista y podemos predecir está bien cuál será la próxima UI en la pantalla y no hay manera de que puedas estar en dos estados diferentes porque solo hay un estado de UI particular. Bien. Así que, aquí quiero introducir la máquina de estados. Así que, es como las tres partes. Una es estados. Así que, como mencioné en la última diapositiva son situaciones nombradas en las que tu aplicación puede estar como idle, scanning, connecting, eventos. Así que, los eventos te ayudan a moverte de un estado a otro como cosas que suceden en el mundo real como el usuario toca conectar, luego el dispositivo encontrado, el enlace se cae, todos son eventos y verificará está bien estás en este estado y recibí este evento solo muévete a una transición de estado diferente. Así que, está más relacionado con eventos. Así que, la transición es como moverse de un estado a otro estás definiendo aquí está bien qué evento debo manejar en este estado particular. Cuáles son las limpiezas, cuáles son los inicios que debo hacer cuando entro en el estado. Así que, por ejemplo aquí puedes ver idle si estoy en idle y recibo un evento de escaneo me moveré a scanning si obtengo una selección como estoy seleccionando un dispositivo para conectar debería moverse a connecting así que yo verificaré diré connecting nuevamente el nuevo evento conectado se moverá a connected y desconectar irá a idle. Así que, aquí la UI solo mirará ese cuadro redondeado como idle, scanning, connecting, connected así que no hay confusión está bien qué UI debería repintar.