¿De Pull a Push? — Es Hora de Hablar Sobre Signals

Hola a todos. Soy Julian, y sí, quiero hablar sobre señales. Ahora, las señales de JavaScript han tenido su buena cuota de atención y entusiasmo en los últimos años. Especialmente en combinación con la propuesta actual de TC39, creo que se vuelve cada vez más importante para la gente entender qué son las señales, cómo funcionan y qué problemas están tratando de resolver. Pero las señales también han sido parte de, digamos, conversaciones menos positivas y discusiones, especialmente en el ecosistema de React en torno a React y su no uso de señales. Así que quiero tocar ese tema. ¿Por qué React no usa señales, qué está haciendo en su lugar, pero también por qué creo que como desarrollador de React, deberías seguir la propuesta de TC39, y personalmente todavía estoy entusiasmado con ella. Ahora, esta no va a ser una charla sobre cómo las señales son correctas, y si no estás usando señales, estás equivocado, o viceversa, como React es correcto, y si estás usando señales, estás equivocado. Para mí, esto no es una situación de correcto o incorrecto. Así que mi charla realmente apunta más a tratar de dar a todos información sobre señales y cómo funcionan, para que, con suerte, puedan irse y tomar decisiones más informadas por sí mismos y tener discusiones más informadas. Pero también, y quizás más importante, quiero resaltar los dos diferentes paradigmas que han evolucionado en el ecosistema de JavaScript y cómo llegamos allí. Así que con todo eso fuera del camino, vamos a sumergirnos directamente en ello y hablemos de señales.

¿Qué son las señales? Comencemos allí, solo para que todos estemos en la misma página. Las señales son la idea de variables reactivas en JavaScript, y lo que eso significa es que podemos ver un ejemplo muy simple. Tenemos tres variables aquí, el contador, y luego dos valores derivados. Así que isEven se deriva del contador y es verdadero o falso, y parity se deriva de isEven y simplemente lo convierte en cadena, par o impar. Ahora, cada vez que reasigno el contador, lo cual puedo hacer porque es solo una variable mutable, tengo que recordar reasignar y recalcular todos esos valores derivados, y eso obviamente no es genial y es tedioso, y la idea de las variables reactivas es que no tengo que hacer eso. Así que imaginemos un mundo, esto no es JavaScript real, esto es un experimento mental y no tiene nada que ver con la propuesta de señales todavía, pero imaginemos un mundo donde tuviéramos un nuevo operador de asignación. Así que elegí el dólar igual en lugar del igual normal, y ese nuevo operador de asignación le diría al compilador que estas son variables reactivas. Así que lo usamos para isEven en parity aquí, el contador puede permanecer igual, y lo que le estamos diciendo al compilador es, oye, por favor, cada vez que cualquier variable que usemos en nuestro cálculo, cada vez que cualquiera de esas cambie, por favor recalcula automáticamente esta variable. Eso significa que si cambiamos el contador, no tenemos que hacer nada más porque la recalculación mágicamente ya sucede a través del compilador. Ahora, esta es la idea central detrás de las señales. ¿Por qué querríamos eso?

La mayoría de lo que hacemos como desarrolladores front-end es lidiar con el estado y convertir ese estado en UI. Ahora, cuando comencé a desarrollar hace bastante tiempo, el paradigma principal alrededor de eso era modelo vista controlador o MVC, y la idea era que tu vista siempre debería ser una función pura del modelo. En términos más modernos, puedes decir que tu UI siempre debería ser el resultado de una función pura de tu estado. Eso probablemente suena familiar, y la parte pura es realmente importante aquí porque básicamente lo que queremos es que si ponemos el mismo estado, siempre queremos obtener la misma UI de ello. Simplemente lo hace muy determinista y fácil de manejar. Ahora, ¿cómo pasamos de eso a señales, que suena más a efectos secundarios? Para entender eso, tenemos que echar un vistazo rápido a la historia de la reactividad en la web. Nuevamente, tenemos que comenzar desde el principio. Comenzamos con HTML y algún tipo de lenguaje de subconjunto.

Estoy eligiendo PHP aquí, pero podría ser cualquier otro lenguaje. Realmente no importa. El concepto es siempre el mismo. Tienes alguna forma de estado. En este caso, tenemos un contador que obtenemos de la URL, y luego tenemos alguna forma de plantillas que usa el estado para renderizar HTML. Luego, en el navegador, cada vez que el estado cambia y cada vez que la URL cambia, el navegador vuelve al servidor, obtiene una nueva UI para ese nuevo estado y la devuelve. Este es básicamente el ejemplo perfecto de lo que acabamos de describir de una función pura que, basada en el estado, simplemente renderiza algo de HTML. Es lo que llamamos el enfoque de extracción. Cada vez que el estado cambia, estamos extrayendo la nueva UI del servidor, y tiene todos los beneficios que acabamos de describir también. Es muy predecible, lo que significa que es muy fácil de razonar al solo mirar el código. Es muy difícil entrar en estados rotos donde tenemos que lidiar con UIs inconsistentes. Pero tiene un gran inconveniente, y ese es el rendimiento. Obviamente no es muy eficiente tener que ir al servidor y obtener el HTML completo nuevamente cada vez que cualquier pequeño cambio de estado ocurre, especialmente en aplicaciones modernas donde tenemos mucho estado flotando.

Así que cuando JavaScript se convirtió en algo, especialmente cuando jQuery se convirtió en algo, y luego obtuvimos AJAX, que nos permitió hacer solicitudes de red incluso después de que la carga inicial haya terminado, comenzamos a jugar con ideas para mejorar este patrón. La idea era básicamente, está bien, sabemos que el estado cambió, y probablemente tenemos una buena idea de qué partes de la UI dependían de ese estado. Así que en lugar de obtener el HTML completo, vamos a obtener solo subpartes de ese HTML, las partes que sabemos que importan. Así que todavía estamos volviendo al servidor, pero ahora somos mucho más selectivos, y solo estamos obteniendo partes más pequeñas del servidor, lo que significa que la respuesta del servidor es, con suerte, más rápida. Así que esto sigue siendo un enfoque de extracción, pero lo llamaría un enfoque de extracción mejorado porque estamos reduciendo el alcance y ayudando con el problema de rendimiento. Estamos introduciendo el potencial de inconsistencias ahora. Si no recuerdas que otra parte de la UI necesita actualizarse cuando el estado cambia, de repente tu UI podría ser inconsistente y estar desincronizada.

Por cualquier razón, desde ese punto, fuimos completamente a JavaScript. Fuimos, ¿y si no fuéramos al servidor en absoluto, sino que simplemente mutáramos el HTML sobre la marcha en JavaScript en el cliente? Aunque esto todavía podría parecer muy similar porque es jQuery, el paradigma cambió completamente. Así que ahora no es una extracción, es más un enfoque de inserción. Así que cada vez que ocurre una acción, en lugar de obtener la nueva UI del servidor, vamos directamente al DOM y empujamos el nuevo estado en él. Eso obviamente pierde todos los beneficios del enfoque de extracción. Así que ahora es mucho menos predecible, más difícil de razonar, y más fácil de entrar en estados inconsistentes. También es bastante desordenado. Así que desafortunadamente, esta es la razón por la que jQuery todavía se recuerda como la era del código espagueti. Para desespaguetificarlo, introdujimos frameworks de aplicaciones. Estoy eligiendo Knockout aquí porque es el primero con el que trabajé.

Podrías haber trabajado con Angular, que salió en un momento similar, u otros frameworks. Todos tienen los mismos principios. Trabajan con tres capas. Una es para la gestión de estado, que aquí es el modelo de vista. Definimos nuestro estado y nuestras acciones allí. Luego tenemos la plantilla donde definimos el HTML que queremos renderizar. Y luego, lo más importante, tenemos esa capa que combina esos dos, que llamamos la capa de enlace de datos, que nos permite acceder a nuestro estado y nuestras acciones dentro de nuestra plantilla.

Entonces, lo que hace es, aunque sigue siendo un enfoque de inserción, así que debajo del capó, Knockout seguirá mutando el DOM. Te da una experiencia de desarrollador que está más cerca de un enfoque de extracción. Todavía tenemos la sensación de tener el control total de lo que se está renderizando en cualquier momento. La otra cosa que Knockout introdujo, que ayuda con eso, es el concepto de observables. Los observables son esencialmente lo que más tarde llamaremos señales. Es el concepto de que el framework puede hacer un seguimiento de esas variables que estamos asignando y puede hacer un seguimiento de cuándo cambian.

Con Knockout computed, podemos definir valores derivados. Nuevamente, se recalculan automáticamente cada vez que cualquier observable dentro de ellos cambia. Eso permitió a Knockout tener esa sensación de que, está bien, solo necesito actualizar un observable, y el framework averigua qué partes de la UI necesito actualizar en base a eso. Aquí es donde el ecosistema de JavaScript se dividió en dos, como mencioné al principio. Entraré en eso en un momento, pero primero enfoquémonos en el camino que lleva a las señales. Básicamente, los observables son la introducción temprana a algo que podrías llamar señales. La idea simplemente se mantuvo. Tenemos muchos otros frameworks que siguen patrones muy similares.

En Vue, teníamos data y computed al principio. Computed siendo simplemente, nuevamente, valores derivados. Todos estos se exponen a la plantilla. En versiones posteriores, o en versiones más modernas, tenemos refs en Vue, que creo, nuevamente, son el mismo concepto. Svelte. No lo verías al principio porque estaba oculto detrás de un compilador, pero en 2019, lo eliminaron e introdujeron Runes, y luego puedes ver que es explícitamente, nuevamente, el mismo patrón. Tenemos una función explícita que nos permite crear estado y estado derivado, y los recalculará por nosotros. Solid fue famoso por ser el que acuñó el término signals, o al menos reciben todo el crédito por ello. Nuevamente, eran muy similares. Tengo una función create signal y una función create computed, y te permiten acceder a esos en tu plantilla. Podría seguir y seguir.

Angular adoptó signals a finales del año pasado. Muchos frameworks están comenzando a converger en esa dirección. Ahora, hablemos del elefante en la habitación. ¿Qué pasa con el otro camino? El camino que tomó React. Entonces, ¿por qué React no está usando signals? Fundamentalmente, React está adoptando el enfoque de extracción. Lo que eso significa es que está diciendo que para construir aplicaciones dinámicas, especialmente aplicaciones dinámicas a gran escala, el enfoque de extracción tiene tantos beneficios de poder renderizar la UI de manera predecible y consistente que vale la pena seguir con ese enfoque de extracción y en su lugar encontrar formas de lidiar con los problemas de rendimiento que vienen con él. Lo que eso significa en React en particular es que podemos ver que cada vez que el estado y un componente cambian, todo el componente se renderizará. Así que, eso es, nuevamente, la extracción, como, simplemente rehacemos todo cada vez que el estado cambia, ese tipo de enfoque.

Hay una charla realmente buena que recomiendo mucho ver de 2014, así que de los primeros días, donde el equipo de React realmente explica por qué idearon Flux como su flujo de estado y React como su biblioteca de UI para resolver problemas, especialmente en la aplicación de Facebook. Y van muy a fondo en ejemplos de los principales impulsores que eran, como, estados de UI inconsistentes. Así que, recomiendo mucho ver eso. También siguen insistiendo en eso, diciendo que el enfoque de React, creen, es simplemente una mejor manera de escribir un código de UI confiable. Pero reconocen el tema del rendimiento. Así que, nuevamente, la forma en que React lo maneja es simplemente tratando de encontrar formas de mejorar el rendimiento mientras se mantiene el enfoque de extracción. Y lo está haciendo de múltiples maneras. Por un lado, la arquitectura de componentes en sí misma ayuda mucho porque no tienes que volver a renderizar toda la aplicación. Solo necesitas volver a renderizar debajo, donde sea que el estado haya cambiado. Así que, eso puede ser muy específico.

React introdujo el concepto de virtual DOM, que permite a React calcular cómo se vería el nuevo DOM, en comparación con el DOM existente, y solo actualizar lo que necesita ser actualizado. Así que, previene renderizados innecesarios para cosas donde la UI realmente no cambió. Y luego hay muchas memorizaciones. Así que, si usas React, sabrás que useMemo, useCallback están básicamente en todas partes. Eso es básicamente, nuevamente, para prevenir cálculos y renderizados innecesarios en tu aplicación. Y están yendo más allá con eso. El nuevo compilador de React básicamente apunta a hacer eso en el propio compilador. Así que, ni siquiera necesitas recordar usar useMemo. Lo hace por ti en tiempo de compilación.

También vale la pena mencionar, y nuevamente, otra charla que recomiendo mucho ver, en la React Conf de este año, el equipo de React mostró una serie de experimentos y benchmarks que han realizado. E incluso han experimentado con signals o implementaciones similares a signals para ver si eso aceleraría el renderizado de React con el paradigma que tienen. Y resulta que realmente no lo hizo. Pero encontraron otras formas que están inspiradas en eso, que son muy prometedoras. Se llama React Fir. No sé si ese es el nombre final, pero vale la pena estar atento a lo que viene allí. Porque nuevamente, el equipo de React trabaja activamente en mejorar el rendimiento mientras mantiene el enfoque de extracción.

Genial. Espero que eso haya dado a todos una idea general de cuáles son los diferentes enfoques, extracción versus empuje, y cómo llegamos al enfoque de empuje donde los signals entran en juego. Ahora, centrémonos en cómo los signals realmente funcionan. ¿Cómo sucede realmente esa magia de saber cuándo recalcular y todo lo demás? Para eso, escribamos un poco de código. Implementemos signals nosotros mismos de una forma muy tonta, muy simplificada. No puedo enfatizar eso lo suficiente. Aún así, nos da una buena idea de cómo realmente sucede. Así que, tenemos una aplicación de demostración aquí. Es solo un botón de contador simple. Y luego estoy renderizando la paridad debajo de él. Y lo que quiero es poder hacer clic en el botón, aumentar el contador, y actualizar la paridad en base a eso. Ahora, en JavaScript puro, probablemente tendría un event listener que tome el contador actual del DOM, luego aumente el contador, y luego actualice el DOM en base al nuevo contador. Y si decimos eso, eso hace exactamente lo que queremos.

Así que, este es el enfoque de empuje donde simplemente estamos mutando basado en acciones. Ahora, el alcance cambió un poco y ahora tenemos un segundo contador. Así que, ahora, necesitamos manejar dos valores de contador, primero que nada, y crear una nueva suma. Usemos eso. Y luego usemos la nueva suma en la paridad también. Si hacemos eso, esto todavía funciona. Pero el nuevo contador también necesita ser conectado. Así que, necesitamos duplicar eso. Es ligeramente diferente. Aumentamos el contador 2 ahora, en lugar del contador 1. Pero el resto sigue siendo muy similar. Y si hacemos eso, genial. Ambos contadores funcionan ahora. Pero ya puedes ver que esto está muy inflado y es ligeramente diferente. Así que, no podemos simplemente extraerlo fácilmente en una sola función. Además, ahora, el PM viene y dice, oye, quiero el tercer botón que aumente ambos contadores al mismo tiempo. Y nuevamente, tenemos que entrar y decir, genial, ahora tenemos un tercer botón. Y hacemos lo mismo. Obtenemos los contadores. Ahora, aumentamos ambos, los sumamos, y actualizamos el DOM nuevamente. Y aunque esto funciona, no hay nada fundamentalmente malo con ello. Esperamos que puedas ver cómo esto se sale de control bastante rápido, en términos de complejidad.

Así que, ¿qué pasaría si tuviéramos una implementación mágica de signals que pudiéramos usar para simplificar las cosas? Lo mejor que queremos simplificar es simplemente extraer, bien, ¿cómo mantenemos el seguimiento de nuestro estado? Esto declara muy fácilmente, estos son los dos signals que tenemos y los valores calculados que tenemos. Y luego podemos pensar, nuevamente, en nuestras acciones. Y todo lo que queremos hacer en nuestras acciones ahora es realmente aumentar los signals, esos signals de contador. Así que, para el botón uno, queremos aumentar el contador uno, para el botón dos, el contador dos. Así que, estamos mucho más enfocados en cómo realmente queremos actualizar nuestro estado. Y luego, en el tercer paso, queremos lidiar con los efectos de lo que realmente queremos hacer con el DOM cada vez que el estado cambia o lo que sea que tu aplicación realmente quiera hacer. Y así, en este caso, nuevamente, muy fácilmente queremos decir, genial, cada vez que el contador uno cambia, vuelve a ejecutar esto y actualiza el texto interno del valor uno y lo mismo para dos y luego la suma y la paridad. Así que, esto ya parece mucho más fácil de manejar.

Obviamente, no hace nada todavía porque no hemos implementado los signals aún. Así que, ese es el siguiente paso. Vamos a implementar esto. Y nuevamente, esta es una versión muy simplificada de signals. Y no es muy útil. Así que, tenemos el valor y todo lo que realmente queremos es un getter que devuelva el valor y un setter que establezca el valor al nuevo valor que estamos pasando. Y para los valores calculados, solo necesitan un getter porque, por definición, nunca establecerías un valor, un valor calculado, solo describirías cómo se calcula. Y para los efectos, por ahora, es lo mismo. Solo ejecutamos la función que se nos pasa.

Y todavía no está haciendo nada porque nos falta esa parte crítica, ¿verdad?, donde los signals saben mágicamente cuándo algo necesita ser recalculado. Y para eso, necesitamos saber quién está usando los signals en primer lugar. Así que, hay dos cosas que necesitamos seguir, el efecto actual, y luego necesitamos tener un concepto de suscriptores. Así que, para el efecto actual, simplemente establecemos el efecto actual cada vez que se ejecuta un efecto. Eso nos permite saber qué efecto realmente usa ciertos signals. Así que, cada vez que leemos un signal, añadimos el efecto actual a los suscriptores. Y luego, después de actualizar cualquier signal, notificamos a todos los suscriptores que el signal ha sido actualizado.

Así que, en realidad, puedes pensar en los signals como pequeños emisores de eventos que simplemente transmiten a todos los que los están usando, oye, he cambiado y necesitas rehacer algo. Nuevamente, esta es una implementación simplificada, pero lo que esto nos da es un ejemplo funcional en nuestro caso. Y son solo 30 líneas de JavaScript. Logramos limpiar gran parte de la implementación del lado de la aplicación de las cosas. Y espero que muestre que, aunque es mágico, en realidad no está sucediendo mucho. Ahora, como mencioné varias veces, estoy simplificando las cosas. Así que, todavía hay desafíos con los que tienes que lidiar cuando implementas signals. Y esto es donde la evolución desde donde venimos con Knockout hasta hoy es muy importante, porque eso es lo que sucedió en esos años. Y no tengo tiempo para profundizar en ninguno de estos desafíos, pero quiero mencionar algunos de ellos solo para darte una idea. Así que, los llamamos glitches. Y hay algunos de ellos. Los populares son que el orden de recálculo importa. Así que, cada vez que un signal cambia, el orden en el que recalculo los valores calculados importa.

Es importante agrupar signals o actualizaciones de signals. En este caso, no hemos incrementado ambos. Y actualizamos dos signals individualmente. Si no los agrupamos, podríamos entrar en un estado donde el estado intermitente después de la primera actualización de signal aparece antes de que se ejecute la segunda actualización. Así que, los frameworks modernos agrupan los signals.

Y luego tenemos muchas optimizaciones que las implementaciones de signals han hecho para rastrear qué valores realmente cambian, si el signal necesita recalcularse o no basado en su dependencia, incluso si el signal raíz ha cambiado, tu dependiente podría no haber cambiado. Así que, los signals a menudo pueden omitir recalculaciones más fácilmente. Y también introdujimos los conceptos de ejecución perezosa.

Así que, los signals se convierten, los valores calculados se recalculan inmediatamente. Solo se marcan como que necesitan ser recalculados o marcados como sucios. Y luego, cuando se leen es cuando realmente los estamos recalculando.