React vs. Tiempo Real: Construye Funciones en Tiempo Real Sin Luchar Contra el Framework

Hola a todos, soy Shubham. Soy un ingeniero de software senior en Headout. Trabajo en DeX Studio, que es una herramienta interna para crear puertas de audio. Entonces, los creadores lo usan para escribir guiones, editar, y publicar puertas. Y recientemente, comenzamos a construir algo mucho más ambicioso dentro de él, que es un editor de plantillas estilo puerta. Entonces, piensa en reproducciones multipista, scrubbing, feeds, un cabezal de reproducción en lienzo a 60fps. Básicamente, todas las cosas que esperarías de un editor de audio de escritorio, excepto que este se ejecuta dentro de una aplicación React en el navegador.

Y mientras lo construía, pasé mucho tiempo enfrentándome a este problema muy específico, que es lo que sucede cuando React se encuentra con sistemas en tiempo real. Y de eso también trata esta charla, que es lo que sucede cuando le pides a un motor de reconciliación que se comporte como un reloj, y más importante, cómo diseñar tu camino alrededor de esa pelea. Así que, durante los próximos 15 a 20 minutos, voy a recorrer cuatro cosas. Primero, el modo Fourier exacto que teníamos. Segundo, el cambio arquitectónico que lo solucionó. Tercero, los patrones que realmente surgen de ese modelo. Y finalmente, discutiremos las compensaciones, porque esta arquitectura absolutamente funciona, pero viene con costos reales.

Así que, ahora, aquí es donde realmente comenzó esta historia para mí. Quiero que imagines tres pistas de audio, un cabezal de reproducción rojo moviéndose suavemente a través de la pantalla. Se supone que debe deslizarse a 60 fotogramas por segundo, pero simplemente no lo hace. Está temblando, el audio entre las pistas se está desplazando, y cada scrubbing está introduciendo un nuevo retraso. Y la parte extraña era que esto no era un problema de hardware. Tampoco era un problema de empaquetador en una red. Esto era React 19 ejecutándose en una máquina rápida, y aquí, el framework estaba luchando contra nosotros a nivel arquitectónico. En retrospectiva, el error era obvio. Estamos pidiendo a React que sea un reloj en tiempo real, y no lo es. Nunca fue diseñado para ser uno. Y hoy, quiero mostrarte qué hacer en su lugar. Así que, vamos a sumergirnos. Si hablamos de React, el ciclo de renderizado de React es eventualmente consistente por diseño. Y honestamente, eso es realmente una característica, no un defecto. Así que, si piensas en cosas como la renderización concurrente, la división de tiempo, las transiciones, el suspense, e incluso el nuevo límite de actividad, todos hacen el mismo intercambio. React se da a sí mismo la libertad de decidir cuándo ocurre el trabajo. Es el framework el que elige el momento exacto.

Y esa flexibilidad es exactamente cómo React se mantiene tan fluido bajo carga, incluso en lugar de colapsar. Pero honestamente, los sistemas en tiempo real no pueden hacer ese intercambio. Y cuando digo en tiempo real, no solo me refiero al audio. La reproducción de audio es obviamente uno de los ejemplos, pero el mismo problema aparece en todas partes. Así que, piensa en un cabezal de reproducción de Canvas a 60 hertz. Piensa en un ticker financiero que actualiza precios en vivo. Piensa en un bucle de control de robots. Todos estos sistemas tienen una cosa en común. Dependen de un reloj que avanza en un horario fijo. Y eso crea una desajuste fundamental.

Así que, si piensas en el modelo de React, el modelo de React puede diferir, reordenar o incluso interrumpir el trabajo. Pero los sistemas en tiempo real no tienen esa flexibilidad. Así que, cuando combinas estos dos modelos ingenuamente juntos, React eventualmente gana. Esto se debe a que es React quien decide cuándo se están comprometiendo tus actualizaciones. Y debido a esto, los usuarios experimentan ese desajuste directamente. Lo escuchan como desplazamientos de audio, lo sienten como retrasos en C, lo ven como fotogramas caídos, e incluso movimientos con jitter. Esta brecha entre dos modelos, entre eventualmente consistente y debe suceder ahora, ese es todo el problema que vamos a discutir.

Así que, veamos cuál es el problema exacto con el que nos encontramos. Así que, estábamos construyendo un editor DOS 10 dentro de una aplicación React. Así que, piensa en tres pistas de audio, un cabezal de reproducción de Canvas corriendo a 60 FPS. Teníamos scrubbing, teníamos fade, teníamos clic para ver. Y al principio, lo implementamos de la manera obvia. Teníamos un use state que estaba llevando un seguimiento del tiempo actual y también teníamos un set interval que estaba tomando cada 16 milisegundos para mantener al menos 60 fotogramas por segundo para trabajar en una pantalla de 60 FPS. Y React estaba volviendo a renderizar la UI en cada actualización. Pero en realidad falló de tres maneras muy específicas. Primero, el cabezal de reproducción comenzó a tener jitter. Esto estaba sucediendo porque React estaba agrupando algunas de nuestras actualizaciones de 60 FPS juntas para priorizar algún otro trabajo. Así que, nuestro cabezal de reproducción comenzó a saltarse cosas. Segundo, el audio entre pistas comenzó a desplazarse. Esto estaba sucediendo porque cada componente de pista básicamente se suscribía al estado de React de manera independiente.

Y debido a esto, cada uno de ellos recibía un tiempo actual diferente. Y esto se debe a que cada pista tenía su propio use effect. Y los callbacks de use effect se ejecutan secuencialmente durante la fase de commit de React. Así que, aunque todas estas pistas parecen sincronizadas en el código, en realidad estaban funcionando en líneas de tiempo ligeramente diferentes.

Tercero, nuestra búsqueda falló de manera muy lenta. Así que, piensa en cada scrubbing que estabas haciendo en la línea de tiempo. Básicamente estaba desencadenando un pase completo de reconciliación de React. Y solo después de que este trabajo se terminaba, nuestro motor de audio finalmente podía recibir la nueva reproducción y la posición. Así que, el scrubbing nunca falló realmente. Y honestamente, estos son tres problemas diferentes. Pero todos provenían del mismo problema raíz, que era, habíamos colocado el estado de React directamente en la parte crítica del sistema en tiempo real, lo que significaba que la señal heredaba el modelo de programación de React.

Así que, veamos. Sigamos adelante. Bien. Antes de entrar en esta arquitectura, quiero que veas esto. Así que, esta es la aplicación. Esta es la aplicación de demostración. Y mostraré todo esto en acción. Así que, a la izquierda, tenemos el estado de React como nuestro reloj. Y en el lado derecho, tenemos el transporte como nuestro reloj. Así que, comenzaremos en modo React. Déjame reproducirlo. Observa el cabezal de reproducción. Está visiblemente entrecortado. Observa el contador de FPS. Está cayendo a alrededor de seis u ocho fotogramas por segundo. Y si puedes ver, tenemos unos 10,000 componentes que básicamente están siendo reconciliados continuamente. Aunque ninguno de ellos cambió visualmente. Ahora, simplemente lo reiniciaré. Y simplemente cambiaré el modo.

Simplemente lo reproduciré de nuevo. Y lo reproduciré otra vez. Ahora, mira, es la misma máquina, misma aplicación, mismos 10,000 componentes. Pero ahora, el cabezal de reproducción se vuelve muy suave. Ha saltado a alrededor de 60 a 70 hertz en una pantalla de 120 hertz. Y si puedes ver, nada sobre la UI cambió visualmente. Aquí, la diferencia es la arquitectura.

En este modo, el cabezal de reproducción se renderiza mediante un bucle de request animation frame. Así que, simplemente lo reproduciré de nuevo. React ya no es responsable del tiempo en este caso. Ya no hay actualizaciones de estado de React. Así que, todos esos 10,000 componentes han dejado de renderizarse completamente. Y ahora solo se renderizan cuando las props realmente cambian. En este caso, React básicamente se ha quedado en silencio y nuestro transporte sigue funcionando. Y en este caso, nuestro scrubbing también se mantiene muy suave. Nuestra reproducción es estable.

Ahora, la pregunta se convierte en, si React es excelente para describir el estado de la UI, ¿por qué le estamos pidiendo que se comporte como un reloj en tiempo real? Y la respuesta es la arquitectura que estoy a punto de mostrarte. Así que, aquí está el cambio arquitectónico. Que es, deja de intentar sincronizar un reloj externo en el estado de React.

Y el navegador realmente lo avanza a una tasa de muestreo, que es alrededor de 48,000 ticks por segundo. Así que, si lo piensas, eso es realmente aproximadamente eso es realmente eso es aproximadamente 20 cada tick está a unos 20 microsegundos de distancia. Ahora, si comparas eso con React, digamos si tienes un presupuesto de renderizado de 60FPS, eso es aproximadamente 16 milisegundos por fotograma. Así que, el reloj de audio es si lo piensas, el reloj de audio es aproximadamente 800 veces más preciso que el presupuesto de fotogramas de React.

Y más importante, está aislado. Así que, el navegador mantiene el reloj en un hilo de mayor prioridad. Lo que significa que el transporte puede seguir avanzando sin importar lo que React esté haciendo. Así que, React en este caso podría estar renderizando componentes o digamos que podría estar ejecutando la recolección de basura o podría estar completamente congelado. Pero el reloj sigue moviéndose. Y eso realmente cambia completamente la ruta de React.

Así que, aquí React ya no es el guardián del tiempo. Se ha convertido en un observador. Este diagrama es básicamente toda la arquitectura. A la izquierda, tenemos nuestra única fuente de hilo, que es el transporte. En el medio, tenemos un bucle ligero de request animation frame. Y a la derecha, el estado de React ahora solo se usa para la sincronización. Y si ves, el flujo de datos es unidireccional. Los datos solo fluyen en una dirección desde el transporte hacia React.

Y nunca fluyen de React de vuelta al transporte. Y una vez que haces ese cambio, el cabezal de reproducción deja de tartamudear. Porque ya no hay nada en la ruta de temporización compitiendo con él.

Así que, hemos hablado sobre el modelo de suscripción. Pero veamos cómo se ve realmente el modelo de suscripción en el código. Muy honestamente, es sorprendentemente pequeño. Es un bucle de request animation que se ejecuta cada fotograma. Lo cual es aproximadamente 60 fotogramas por segundo.

Cada fotograma, lo que hacemos es, básicamente leemos del transporte. Y luego lo convertimos en milisegundos. Y lo enviamos a una devolución de llamada. Y lo que hace esa devolución de llamada es, básicamente publica la última versión en una capa de suscripción ligera. Y cuando hacemos eso, nuestro cabezal de reproducción se suscribe directamente a ese valor. Y debido a esto, solo el cabezal de reproducción se re-renderiza. Y honestamente, ese es todo el bucle. Así que hay tres cosas importantes sucediendo aquí. Primero, no hay tiempo dentro de React.

Así que no hay intervalos establecidos, no hay tiempo de espera establecido, básicamente no hay estado de contador local siendo actualizado dentro del use effect. Así que aquí, React ya no está avanzando. En segundo lugar, tenemos el transporte como nuestro reloj canónico. Así que debido a esto, nuestra fuente de verdad vive completamente fuera del árbol de React. No estamos leyendo del estado de React, estamos leyendo directamente del reloj de muestra del motor de audio. En tercer lugar, si digamos, React pierde un fotograma porque algún otro componente está ocupado renderizando, nada se rompe eventualmente en nuestro caso. Y lo que sucede es que el siguiente fotograma simplemente lee la posición actual del transporte nuevamente. Y si ves el reloj en sí. Porque el reloj nunca se ralentizó.

Y la idea clave aquí es que no hay desviación de la que recuperarse, porque nunca simulamos el tiempo dentro de React en primer lugar. Así que si ves, React no está ejecutando el tiempo. Ahora es un observador del tiempo. Ahora, suscribirse al transporte resolvió el problema de temporización. Pero luego expuso un problema más que es a 60, si lo piensas, a 60 fotogramas por segundo, incluso pequeñas actualizaciones de React se vuelven muy costosas si la línea de tiempo se redibuja continuamente. Lo que hicimos fue, también cambiamos la arquitectura de renderizado.

De alguna manera dividimos la capa del lienzo en, de alguna manera dividimos la capa del lienzo, una sola capa de lienzo en dos capas. Primero, una capa fría. Segundo, una capa caliente. Así que piénsalo de esta manera, la capa fría contiene todo lo costoso, pero mayormente estático. Así que piensa en pistas, reglas y etiquetas. Y esa capa está agresivamente en caché y solo se redibuja cuando la estructura cambia. Y cuando hablamos de cambios estructurales, me refiero a hacer zoom, cambiar el tamaño, agregar pistas y cosas así.

Y luego tenemos nuestra capa caliente. Así que la capa caliente contiene exactamente una cosa, que es el cabezal de reproducción. El cabezal de reproducción básicamente se redibuja en cada cuadro de animación, que es impulsado, que en realidad es impulsado directamente por el bloque de transporte. Así que ahora nuestro sistema opera a dos frecuencias completamente diferentes. La UI pesada se dibuja raramente, la pequeña UI en movimiento se redibuja básicamente constantemente. Y debido a que esos caminos están aislados, nunca se bloquean entre sí. Y honestamente, este patrón se generaliza más allá de las herramientas de audio.

Si piensas en cualquier pequeña pieza de UI que se mueve a alta frecuencia sobre contenido mayormente estático, la misma arquitectura se aplica. El truco es simple, identificar los píxeles calientes y almacenar en caché todo lo demás. Ahora, este mismo patrón aparece nuevamente con la entrada del usuario. Así que quiero que imagines arrastrar un control deslizante de volumen en un editor de audio. Así que en este caso, el usuario básicamente espera que el sonido responda instantáneamente y no solo bastante rápido. Lo dicen en serio, quieren que sea instantáneo.

Así que enrutar cada arrastre a través del estado de React se convierte en un problema. Entonces, lo que hicimos fue que durante el gesto, el motor de audio se actualiza directamente en React Jam. Así que tratamos de evitar el estado de React. Así que React nunca ve los valores intimados. Solo recibe el estado final asentado después de que la interacción ha completado. Y honestamente, ese límite resulta importar mucho.

Aquí, la retroalimentación en tiempo real evita React y el estado de persistencia se compromete con React. Y este es en realidad el mismo principio que el reloj de transporte. React posee la identidad y el subsistema en tiempo real posee la semejanza. Y una vez que notas este patrón, comienzas a verlo en todas partes, como, digamos, herramientas de pincel, manejadores de redimensionamiento, cursor colaborativo, vistas previas en vivo, y mucho más. Y eso es un flujo continuo de valores en progreso.

Así que si lo piensas, el flujo continuo de valores en progreso es temporal. React almacena el resultado, no el movimiento. Así que sigamos adelante. Bien, un principio más antes de entrar en las compensaciones. En los sistemas en tiempo real, las invalidaciones de caché importan mucho. Así que piensa en el tipo de cosas que almacenamos en caché. Digamos que almacenamos en caché buffers de audio, texturas de video, hilos de trabajo, módulos compilados. Y estos son en realidad objetos costosos. Recrearlos innecesariamente es sinceramente un desastre de rendimiento.

Así que aquí, nuestra clave de caché se vuelve muy crítica. Así que tomemos el buffer de audio como ejemplo. En el buffer de audio, nuestra URL de archivo es la identidad. Así que si la URL cambia directamente, es un recurso completamente diferente. Pero cosas como volumen, paneo, o desvanecimientos, o efectos no son identidad. Son solo comportamiento en tiempo de ejecución. Nunca deberían invalidar el buffer subyacente. Así que lo que hicimos fue hacer esa distinción explícita en la clave de caché.

Así que piénsalo de esta manera. La identidad va en la clave, pero el comportamiento no. Lo que significa que alguien puede arrastrar el control deslizante de volumen durante horas y el buffer de audio nunca se recargaría. Y sinceramente, este patrón nuevamente se generaliza sorprendentemente lejos. Digamos claves de caché, dependencias de memoria, dependencia de efectos, claves de consulta, todos están respondiendo la misma pregunta. ¿Este valor cambia dónde está la cosa, o solo cómo se comporta actualmente? Una vez que separas esa identidad del comportamiento, realmente evitas una enorme cantidad de invalidaciones accidentales.

Así que ahora hablemos de las compensaciones. Ahora, esta arquitectura funciona absolutamente, pero no es gratuita. Una vez que mueves el estado en tiempo real fuera de React, también asumes la responsabilidad de los problemas que React normalmente resuelve por ti. Primero es realmente la accesibilidad. Así que durante interacciones en vivo, React ya no ve cada valor inmediato. Así que cosas como lectores de pantalla y actualizaciones de áreas dejan de suceder automáticamente. Ahora tienes que sincronizar el estado de accesibilidad manualmente. Segundo es nuestra coordinación.

Así que tus sistemas en tiempo real siguen funcionando independientemente del árbol de React, pero características como suspense pueden pausar temporalmente tu parte de la UI, lo que significa que la UI y el motor subyacente pueden desincronizarse silenciosamente a menos que los coordines explícitamente. Y tercero es la depuración. Así que una vez que el trabajo importante ocurre fuera de React, las herramientas de desarrollo de React dejan de mostrar el panorama completo, que tu perfilador de React puede parecer perfectamente calmado mientras los bucles de animación, las tuberías de renderizado y los programadores en tiempo real todavía están ocupados en otros lugares. Así que tu modelo de depuración cambia de las herramientas de desarrollo de React hacia las herramientas de rendimiento del navegador. Y ninguno de estos problemas es insoluble, pero son sinceramente costos reales de ingeniería. Y estos son los costos que React normalmente absorbe por ti cuando todo permanece dentro del estado de React. Así que sigamos adelante.

Así que aquí está la conclusión principal. Si tu aplicación tiene tiempo real medido en milisegundos y no solo se siente receptiva, sino que tiene restricciones de tiempo real reales, esas garantías probablemente no pertenecen dentro del ciclo de renderizado de React. Así que si lo piensas, React es excelente para describir el estado de la UI, pero no es un programador en tiempo real. Así que el cambio arquitectónico es simple. No hagas que React esté a tiempo, haz que React se suscriba al tiempo. Deja que un sistema externo avance independientemente y deja que React lo observe.

Así que para interacciones en vivo, y lo que quiero decir es, para interacciones en vivo, deja que las actualizaciones en tiempo real pasen por alto React y se comprometan de nuevo a React solo cuando la interacción se haya estabilizado. Y otra conclusión es que al almacenar en caché recursos costosos, almacena en caché basado en la identidad, no en el comportamiento temporal. Y en cualquier lugar donde la reconciliación del marco, y otra conclusión sería en cualquier lugar donde el tempo de reconciliación no coincida con el tempo de la experiencia del usuario en el mundo real, eso es en realidad una señal para separar el reloj del marco de la UI. Y honestamente, eso es todo. Simplemente no dejes, no pidas a React que mantenga el tiempo, deja que reaccione al tiempo. Gracias por tu tiempo.