Construye Tu Propia Reactividad: Un Análisis Profundo de los Signals

Muy bien. Hola. Hola a todos. Encantado de estar aquí. Mi nombre es Karl Vorden y hoy voy a hablar sobre señales y de hecho vamos a construir una. Antes de entrar en eso, tal vez una rápida muestra de manos. ¿Cuántos de ustedes han usado señales alguna vez? Sí, bastantes. Sí. Bien. Y el resto de ustedes, ¿cuántos han oído hablar de señales? Creo que eso es el resto de ustedes. Y tal vez aquellos que levantarían la mano, probablemente sean desarrolladores de React. Solo bromeo. Solo bromeo.

Bien. Entonces, las señales son básicamente un contenedor para un valor. Nada especial en eso. Pero con ello, el estado y la interfaz de usuario se actualizan automáticamente cuando el valor cambia. Y así, esta es la parte que es la reactividad. Y bueno, ¿por qué querríamos construir esto nosotros mismos? Porque ya hay muchas implementaciones. Bueno, eso es principalmente con fines de aprendizaje.

Pero para que puedas usarlo efectivamente, es útil entender cómo funciona internamente para que en caso de que te encuentres con algún problema, puedas fácilmente, más fácilmente, como averiguar qué está pasando. Y al menos para mí, cuando veo una pieza de tecnología que es nueva para mí, parece un poco mágica. No entiendo realmente qué está pasando internamente. Tengo curiosidad por saber cómo funciona y realmente entenderlo mejor. Así que ese es el objetivo aquí. Así que todos vemos que no hay magia. Es solo JavaScript. Y bueno, obviamente, no es la única manera de lograr reactividad. React tiene el DOM virtual donde ejecutas la función de renderizado nuevamente y construyes un DOM virtual y lo comparas con el DOM real.

Sí, también funciona. Logra reactividad. Y en Angular, está la verificación sucia donde mantienen un seguimiento de todos los valores que están usando en la plantilla y luego los comparan cada vez que sucede algo. Y bueno, ambos enfoques podrían no ser los óptimos. Hay mucho trabajo que tienes que hacer cada vez. Entonces, ¿por qué son buenas las señales?

Bueno, con las señales, obtenemos una reactividad más detallada y eficiente porque solo se actualiza y recalcula el código que usa los valores que cambian. Y no tienes que hacer ningún trabajo adicional allí. Así que esta es la manera. Pero antes de comenzar la implementación, ¿qué necesitamos? Número uno, necesitamos saber quién usa el valor.

Y el número dos es que necesitamos saber cuándo cambia el valor. Estos dos puntos son la clave, y llegaremos a ellos más adelante cuando hagamos la implementación real. Comparación rápida con una variable común y corriente. Sí, también es un contenedor para el valor, pero no sabe quién lo usa.

Pero en JavaScript, tenemos estas cosas mágicas llamadas funciones. Así que desde una función, podemos devolver un valor contenido, y podemos pasar un nuevo valor. Así que esa es la parte del contenedor. Una función sabe cuándo se llama. Sabes, se ejecuta. Pero, ¿sabe quién la llama? Bueno, eso es algo que tal vez necesitemos averiguar.

Pero antes de sumergirnos en el código real, veamos algunos pequeños ejemplos de diferentes implementaciones de señales en los frameworks actuales. Aquí están las señales de Solid JS. Ves que hay una función createSignal, que devuelve dos funciones, count en este caso, y setCount. La primera es la función getter. La llamas y obtienes el valor. Luego, la segunda es la función setter. Puedes llamarla para dar un nuevo valor.

Y para todos los desarrolladores de React, podría parecer un poco familiar a useEffect y cosas así, pero funciona de manera totalmente diferente bajo el capó. En el fragmento a continuación, puedes ver cómo puedes usarlo en la plantilla. En Angular, tenemos una función llamada signal para crear una, y solo devuelve una cosa, que es como una función. Puedes llamarla para obtener el valor, pero también es como un objeto porque tiene un método dot set donde puedes establecer el nuevo valor. Así que un enfoque un poco poco convencional, en mi opinión, pero, sí, funciona.

Luego en Vue, las señales se llaman refs, y creas una con la función ref, y lo que obtienes de vuelta es un objeto. El objeto tiene un punto value que parece ser una propiedad, pero en realidad, bajo el capó, está implementado con una función getter y una función setter. Así que es, de nuevo, dos llamadas a funciones, aunque no lo parezca aquí. Puedes simplemente hacer el plus plus, y en realidad lo que sucede son dos llamadas a funciones. En la plantilla, no tienes que poner el value, pero eso es porque Vue lo analiza y lo maneja por ti.

Luego también está en Svelte, por ejemplo, la implementación de señales se llama runes, pero no tenemos tiempo para profundizar mucho en eso. Bien. Así que comencemos a construir algo. Voy a tener que ir bastante rápido porque el límite de tiempo es de 20 minutos, así que espero que puedas seguir y trataré de explicar. Así que primero comenzaremos definiendo la función signal, que actúa como el contenedor para el valor. Devolveremos un objeto que tiene un método getter y un método setter para el valor. Así que en este caso, lo haremos un poco al estilo de Vue.js usando los métodos getter y setter. Pero en este punto, lo que tenemos no es tan emocionante aún. Es básicamente como una variable que podemos instanciar, y luego podemos cambiar el valor. Y si hacemos console.log así, y si luego ejecutamos, sí, no es tan emocionante.

Pero antes, cuando dije que la función sabe cuándo se llama, no es nada emocionante, solo que podemos ejecutar código aquí. Eso es básicamente lo que quiero decir. Podemos ejecutar código aquí para que podamos ver que los métodos get y set se llaman cuando el valor se usa dentro de la función. Ahora, si recuerdas de la diapositiva, había dos puntos. Así que el primero era saber cuándo cambia un valor, perdón, saber quién usa el valor. Así que para comenzar con eso, aquí en el método getter, necesitamos rastrear quién usa el valor. Para eso implementaremos una función track, que tomará una señal como parámetro. Y luego necesitamos un lugar para almacenar de alguna manera el uso. Así que definamos un usage ya que usaremos un WeakMap para esto. Y la razón por la que estamos usando WeakMap es que en lugar de un objeto normal, podemos usar el objeto de señal en sí como la clave. Así que podemos verificar si ya hay algo allí. Y si no, entonces podemos establecerlo como un array vacío. Y luego continuando, obtendremos, y luego tendremos el array y pondremos algo en el array. Pero, ¿qué deberíamos poner allí? Bien. Ahora, el objetivo aquí es que podamos deshacernos del segundo console log.

Y solo definiríamos console log una vez y se ejecutaría cada vez que un valor cambie. Y para eso necesitamos una segunda parte de las implementaciones de señal, que es una función llamada effect. Y toma una función callable como parámetro, que luego ejecuta. Y luego podríamos definir nuestro console log como reactivo, por así decirlo. Entonces, ¿cómo hacer que esto funcione?

Ahora, como podemos ver aquí, el valor ahora se lee dentro de la función effect. Y esta función effect es también lo que queremos ejecutar nuevamente más tarde. Así que necesitamos hacer un seguimiento de lo que sucede durante la ejecución del effect. Así que podemos definir un current effect, al cual asignaremos la función callable antes de ejecutarla. Y después de ejecutarla, la eliminamos. Y esto es lo que pondremos en los usages, pero solo si hay uno.

Bien. Me gusta esto. Ahora, la segunda parte, número dos, era saber cuándo cambia el valor. Y eso sucede en la función setter aquí. Y así, en lugar de console logging, ejecutaremos. Y definamos una función execute. Toma una señal. Y luego obtendremos de los usages de esta señal, que podría no estar allí, así que jugaremos a lo seguro. Y es un array de los callables, que luego ejecutaremos. ¿Piensas?

Solo para ver, pongamos algunos más aquí. Y es una señal reactiva. Y, bueno, normalmente nuestro estado no consiste solo en valores simples únicos, como números y cadenas. Necesitamos formas de combinarlos y hacer cálculos sobre ellos. Así que hagamos también una tercera parte de la parte común de la implementación de señales, que es computed. Así que con computed, podríamos definir un, llamémoslo un double. Y toma una función.

Y dentro de aquí, podríamos usar nuestro valor de prueba y duplicarlo. Y luego podríamos usarlo aquí dentro del effect así. Y, como puedes ver, el computed debería actuar como una señal en sí misma. Tiene el punto value, pero también toma una función, así que es como un effect.

Así que lo que necesitamos hacer es definir una señal aquí, que devolveremos. Pero aquí en medio, asignaremos el resultado del callable a la señal. Pero para hacerlo reactivo, también lo envolveremos en un effect así.

Pero para hacerlo reactivo, también lo envolveremos en un effect así. Y ahora todo está funcionando así. Así que nosotros... Gracias. Gracias.

Así que para recapitular rápidamente, definimos una señal de prueba, creamos un computed donde usamos la señal, y luego definimos un effect donde usamos el computed. Así que cada vez que un valor cambia aquí, primero recalcula el computed, que luego activa el effect nuevamente.

Y el resultado es lo que vimos. Y una rápida recapitulación es, definimos una señal como el contenedor de un valor.

Definimos un effect, que rastrea señales que están durante la ejecución de la función. Y luego nuestras actualizaciones de señal desencadenan la re-ejecución del effect. Y finalmente, hicimos el computed, que es solo un poco de azúcar sintáctica para una señal calculada a partir del effect.

Ahora que sabemos cómo funciona la implementación, podemos observar algunos posibles escollos. Como, en primer lugar, los condicionales son algo muy básico de hacer en programación. Así que si estamos usando declaraciones if, declaraciones switch, o algo así dentro de nuestros effects, podría causar a veces que todas las señales que realmente se usan dentro de él no se ejecuten.

Y en ese caso, el sistema no lo sabe. Así que solo puede conocer aquellas señales que realmente se leen durante la ejecución del effect. Otro es async.

Si tuviéramos código dentro del effect que usa promises o callbacks o timeouts o algo así, entonces las funciones que pasamos a esos, no se ejecutarán hasta más tarde. Y si recuerdas, el effect actual solo se asigna durante la ejecución de la función invocable. Así que nuevamente, no van a ser rastreados. Así que este tipo de situaciones pueden causar problemas difíciles de depurar porque no pasa nada y piensas que debería pasar algo. Pero cuando sabes cómo funciona internamente, entonces puedes intentar razonar más fácilmente sobre lo que está sucediendo.

Y finalmente, destructuring. Básicamente, si sacas el valor del contenedor, entonces ya no funciona. Esto es más común tal vez con objetos reactivos que con signals porque los signals solo contienen un valor, así que no es tan común sacarlo. Pero por ejemplo, en Vue, hay un objeto reactivo que se conecta al mismo sistema de reactividad. Y con objetos que tienen muchas propiedades, es más común usar destructuring para sacar solo algo que necesitas. Pero si luego lo usas en un effect, no funciona porque está fuera del contenedor.

Bien. Ahora que tenemos tal vez unos minutos de tiempo, usar solo console logging no es tan emocionante, así que hagamos otra demostración. Así que solo para darte un pequeño aviso, esta demostración va a tener HTML puro, JavaScript puro, sin framework, sin empaquetado, sin construcción, nada. Pero no te preocupes. Soy un profesional capacitado. Puedo manejarlo. Bien. Tengo este pequeño fragmento de HTML aquí. Y... Importa esta implementación de signal que acabamos de hacer. Da algunos errores. Ahora solo tenemos que hacer las exportaciones aquí para las tres funciones que usamos. Todo lo demás son internos. Solo exporta estas tres. Y lo que haremos es... Hagamos una calculadora, si puedo escribir. Bien. Esto es un poco demasiado grande, creo. Bien.

Así que para esto necesitamos algunas signals. Las llamaremos value one, value two, y operation. Y he preparado un pequeño fragmento de HTML aquí. Tenemos un campo de entrada numérico y luego un desplegable para las operaciones y otro campo de entrada. Y estos están actualizando las signals aquí.

Y para comenzar nuestra implementación, definamos un result como computed. Y primero, solo para verificar que nuestras signals están funcionando, hagamos un console log de ellas rápidamente. Así. Y luego podemos ver, bien, sí, parece estar funcionando. Continuemos usando un switch en la operation.

Y luego tengamos algunos casos. Return value one plus value two. Y luego hagamos esto cuatro veces para todas nuestras diferentes operaciones. Bien. A continuación, si estuviéramos construyendo algún framework, entonces solo escribiríamos algo como esto y funcionaría mágicamente. Pero en este caso, tenemos que hacer lo que los frameworks realmente hacen cuando analizan tu plantilla y encuentran código como ese.

They will create an effect. Y dentro del effect, escribirán código que actualiza el DOM. Así que iremos directamente al inner HTML. Ponemos un signo igual y luego el result value o tal vez vacío. Bien. Ahora, veamos. Doce por cuatro. Bien. Ahora, cada vez que cambio este valor o este valor o la operation, se actualiza automáticamente.

Y, bueno, una pregunta. Si hacemos un plus, ¿alguien sabe cuánto es 13 plus 5? 135. ¿Sabes por qué? Sí, lo sabes, porque esto es JSConf. Sí. Bien. Eso fue todo. Soy Karl Vorden y estoy en BlueSky y en GitHub. Están las diapositivas y demos en mi GitHub si quieres echar un vistazo. Sí. Gracias.

Gracias, Karl. La primera es bastante, ¿es la implementación subyacente similar a lo que hace MobX? Sí, creo que un poco. MobX usa sus proxy objects, pero es un poco similar. ¿Hay un beneficio en usar un proxy object sobre getter y setters? Bueno, es solo que el object puede tener muchas propiedades en lugar de solo una o predefinidas. Sí. Bastante justo. Bastante justo. Bien. No sé qué pasó allí. Creo que marqué una pregunta antes de responderla. La siguiente pregunta es, ¿cuál es la diferencia entre un signal y un proxy? Bueno, creo que el signal es más como la reactividad.

Así que, no es solo – puedes implementar algo como signals con los proxies, pero también necesita la parte de effect para que algo suceda. Así que, como ya dije, en la charla, Vue.js tiene el concepto de reactive object que también se conecta a la misma reactividad. Así que, en Vue, esos se implementan con proxies. Y luego hay otras cosas que puedes hacer con proxies que no son reactividad. Sí. Así que, se puede usar. Sí. Los proxies son siempre uno de esos – para mí, siempre son como esa cosa que va en los frameworks. Realmente no los usas tú mismo. Sí. Toca esos proxies.

Y una cosa que olvidé decir durante la charla, que esta implementación, obviamente, es bastante ingenua. Hay mucho espacio para mejorar. Y así, la implementación real es obviamente un poco más larga. Más eficiente. Si pudiéramos construir implementaciones completas en solo 20 minutos, entonces ya nos habríamos quedado sin trabajo. Sí. Excelente.

Muy bien. Alguien preguntó – bueno, alguien dijo que era una gran manera de aprender. También me gusta el live coding como una forma de ver algo. También te animo a que tal vez intentes construir tu propio y aprendas más. Absolutamente. Pero la pregunta era – Construir uno mejor. Construir uno mejor, sí. La pregunta era, ¿has visto a Evan hacer una demo como esta alguna vez? No, no lo he visto. Tal vez algo más para revisar después. Además, si disfrutas del live coding de la implementación de signals, solo necesitas bajar porque ayer me enteré de que Paula, cuya charla es la siguiente abajo, está haciendo exactamente lo mismo. Genial.

Pensé que sería realmente interesante. Pero es un poco específico de SWELT. Así que, si te interesa SWELT, baja. Será una perspectiva ligeramente diferente sobre el tema de SWELT. En realidad, te da una buena visión general de todo el asunto, creo, lo cual es bastante genial, sí.

Muy bien. ¿Tienes un framework de signals favorito? Principalmente, he estado usando Vue, así que tal vez ese. Pero no lo sé. ¿Tienen todos pros y contras? Sí. ¿Contras? Sí. Porque los signals han sido una propuesta para JavaScript. ¿Eso sigue en proceso? Pero incluso si se aprueba, no es algo que usarías en tu código. Es más para que los desarrolladores de frameworks construyan sobre ello porque todavía necesita la parte específica del framework para conectar la reactividad en el framework.

Entendido, entendido. Supongo que una vez que eso se apruebe, será más fácil para esos desarrolladores de frameworks hacerlo. Sería más eficiente si el sistema se conecta a código C y cosas así. Genial. Muy bien. Bien, entonces una pregunta sobre React en esto. ¿Cuál es – o sabes cuáles son las mayores ventajas para React de usar Shadow DOM y su versión de – no es realmente reactividad, supongo, en lugar de signals como has mostrado? No soy un experto en React. Creo que todo el concepto de cómo han construido el framework, no sería fácil para ellos usar signals, creo. Sí, rompe todo el React, como, la UI como una función de estados, ¿verdad? Porque el estado cambia sin – y conecta diferentes partes de él individualmente en lugar de hacer todo el árbol.

Diferente forma de verlo totalmente. Así que es poco probable que veamos que React realmente se incline hacia los signals. Aunque React tiene signals, así que no sé qué están haciendo. Tendré que investigar eso tal vez, supongo, sí.

¿Es este patrón útil sobre los frameworks? ¿Hay algún ejemplo que puedas dar sobre eso? Sobre los frameworks, creo que – bueno, incluso podrías usar una biblioteca de signals independiente para algo si necesitas algo de reactividad en tu propia lógica de negocio. Pero si usas un framework específico, entonces la reactividad debería estar conectada al framework de alguna manera para hacer que la UI sea reactiva. Tal vez si quieres usarlo solo para cosas de lógica de negocio. Sí, justo. Necesitas esa interacción del framework para realmente obtener los beneficios de ello. Sí.

Genial. Una pregunta más. ¿Sabes por qué este patrón se llama un signal? No. No tengo idea. No es un concepto nuevo. Es bastante antiguo, en realidad. Muy bien. Bueno, voy a detener las preguntas ahí. Pero hay más oportunidad – otro vaso se ha ido – hay más oportunidad de hacer nuestras preguntas sobre esto en el Q&A en el primer piso. Así que ve a encontrarlos allí. Pero de lo contrario, dales un gran aplauso por una increíble actuación de codificación en vivo.