Surprise! Svelte Secretly Sending Signals

Bienvenidos, a todos, a mi charla. Se llama ¡Sorpresa! Svelte Secretly Sending Signals. Antes de comenzar, se debe hacer una pequeña presentación. ¿Quién soy? Soy Paolo Ricciuti. Vengo de Campobasso, Italia, la tierra de la pizza. Y me puedes encontrar en BlueSky como paolo.ricciuti.me o en GitHub como Paolo Ricciuti. Soy un embajador de Svelte y un mantenedor de Svelte, y trabajo como ingeniero de software senior en es súper genial, porque puedo trabajar con Svelte pero también enseñar Svelte, tanto en meetups como en conferencias, así como esta, pero también en mi trabajo diario porque hacemos lo que se llama aumento de equipo, lo que significa que nos unimos a tu equipo, te ayudamos a contratar, te enseñamos Svelte y las mejores prácticas. Incluso hacemos masterclasses. Así que si quieres, puedes escanear este código QR y también obtener el código JS Nation 25 para un 25% de descuento. Y también tenemos un servicio de API de suscripción, no servicio de API, para que si no tienes un proyecto completo, básicamente obtienes acceso a nuestra experiencia, como, en Slack, y puedes básicamente, como, pedirnos que revisemos un código y cosas así.

Pero es hora de la demostración, porque esto será 100% codificado en vivo, porque aparentemente me odio a mí mismo. Así que cambiemos a VS Code, donde nos encontramos con la demostración más inútil. Es un contador que no funciona a menos que mantengas la fiesta en marcha. Y luego puedes, como, escribir aquí, y se actualizará en la parte superior. Pero lo interesante es cómo está todo conectado. Así que esto está conectado con la forma antigua de hacer reactividad en archivos JavaScript en Svelte, que es con una tienda escribible. La tienda escribible es básicamente el patrón de observador, y puedes ver una implementación aquí. Son, como, 20 líneas de código. Y cómo lo usas también es muy simple. Como, solo declaras el estado escribible, y puedes suscribirte a él, y esta función se invocará cada vez que cambie el estado. Y luego, como, este es un proyecto vanilla, así que estás conectando el botón, el listener de clics, y así es como actualizas el estado, que es...

Pero veamos la implementación. Así que pasas un valor inicial, almacenas el valor aquí, y luego tienes un conjunto de suscriptores, y aquí, un conjunto es solo un array elegante sin repeticiones. Y luego tienes una función de suscripción que toma una función como entrada, la almacena en el suscriptor, la invoca con el valor actual, y luego devuelve una función para desuscribirse. Luego tienes la función set que simplemente, como, establece el nuevo valor, como, el valor al nuevo valor, y luego recorre cada suscriptor y llama a la función con el valor. La función de actualización es aún más fácil porque solo llama a la función set. Y el valor que estás pasando es esta función get new value. Ahora, como puedes ver, usar la tienda, los escribibles, no es realmente bonito. Y Svelte es famoso por su vibra, como, queremos hacer las cosas más simples. Así que permíteme presentarte la API proxy.

Así que puedo hacer const P es igual a un nuevo proxy. La API proxy es muy simple, y básicamente, obtienes un objeto como este, y luego el segundo argumento es en realidad una serie de trampas. Y al igual que un proxy de red donde puedes interceder en una solicitud, puedes básicamente interceder en operaciones en tu objeto. Por ejemplo, existe la trampa get, y en la trampa get, obtienes el objetivo y la clave que estás tratando de acceder. Y puedes devolver target en key para target en key para el valor predeterminado. Pero también puedes agregar, no sé, console.log obteniendo la clave. Y si haces esto, y necesito algo aquí. Si haces esto, y si intento hacer console.log p.name, y si guardo, puedes ver que en este caso, estoy obteniendo el valor, que es Paolo, y estoy obteniendo el nombre, que es una especie de efecto secundario. Pero en lo que realmente estamos interesados es en la función set. Así que puedes obtener un objetivo, la clave y el valor. Y obviamente, puedes obtener el comportamiento predeterminado con target en key es igual a value. Necesitas devolver true, de lo contrario, obtendrás un error. Pero incluso aquí, puedes hacer algún efecto secundario, básicamente. Así que si guardo, y si hago p.name es igual a JS nation, y guardo, puedes ver que estamos obteniendo establecer nombre, JS nation, y luego estamos obteniendo el valor real. Así que básicamente, podemos reemplazar estos con nuestra función set. Y así, en lugar de devolver este objeto, podemos hacer return new proxy.

Ahora, necesitamos pasar un objeto en este caso. Así que no podemos pasar valores literales más. En Svelte, no tenemos esta limitación porque es un compilador. Así que puedo eliminar esto porque, dado que es un objeto, el usuario puede acceder al objeto directamente ya que es una referencia. Y aquí puedo básicamente hacer set, obtengo el objetivo, obtengo la clave, obtengo el valor, y luego puedo básicamente hacer lo mismo que estaba haciendo aquí. Así que puedo básicamente establecer el target en key igual a value para actualizar el valor. Necesito devolver true como he guardado. Y luego podemos simplemente llamar a nuestra lista de suscriptores, la función nuevamente. Así que, obviamente, puedes notar que ahora tenemos un problema porque no tenemos una forma de suscribirnos a ello. Así que por el momento, hagamos algo sucio y devolvamos una tupla. Y el primer argumento será nuestra función de suscripción. Así que básicamente, puedo hacer exactamente esto dentro de esta función. Y, obviamente, ya no necesito el valor porque no está allí. Ahora, podemos actualizar nuestro código ahora para que podamos eliminar todos estos.

Y necesitamos, por el momento, actualizar esto para sacar el subscribe de ello. Necesitamos actualizar todo este state dot subscribe para que sea solo subscribe. Decimos que ya no necesitamos este signo de dólar state como entrada porque ahora, estamos simplemente haciendo, estamos accediendo al estado por defecto. Y ahora, la parte divertida es que podemos actualizar todo este código.

Y aquí, podemos simplemente hacer state dot count más más, lo cual es mucho, mucho más agradable. Y podemos hacer lo mismo aquí. Podemos hacer state dot checked es igual a e dot target dot checked. Y podemos eliminar todo esto. Y luego podemos hacer state dot value es igual a e dot target dot value. Y podemos eliminar todo esto.

Ahora, si hice todo correctamente y guardo, deberíamos tener literalmente lo mismo. Y no es, obviamente. ¿Qué me perdí? Subscribe, subscribe. ¿Me perdí algo? Oh, ¿qué? ¿Cómo estaba ahí? Sí. Debería ser esto. Yep. Así que ahora, esto es literalmente lo mismo. No tengo que hacer nada. No tengo que hacer nada. Solo tengo que hacer, como, lo mismo. No tengo que hacer nada. No tengo que hacer nada. Solo tengo que hacer, como, lo mismo. Solo tengo que hacer, como, esto. No tengo que hacer nada.

No tengo que hacer nada. Solo tengo que hacer, como, esto. {{^}}No tengo que hacer nada. Así que ahora, esto es literalmente lo mismo que antes. Así que funciona y está bien.

Ahora, podemos ir a casa. Está bien. El problema es que digamos que hago console.log corriendo. Y si guardo, obviamente, ahora, está corriendo la primera vez. Y si desmarco la casilla, está corriendo. Y esperamos eso, porque checked cambia. Y si cambiamos el número, está corriendo de nuevo, lo cual esperamos, porque count cambia. Pero si desmarco y luego cambio count, sigue corriendo, aunque la UI no está realmente cambiando.

Pero, quiero decir, esto tal vez sea aceptable. Lo que realmente no es aceptable es esto. Si cambio el valor, aunque no estoy usando el valor aquí, todavía estoy ejecutando ese código. Así que no quiero hacer eso. Y la razón de esto es que estamos usando un set, así que esto significa que solo tenemos un conjunto de suscriptores para todas las claves. Puedo cambiar esto si hago map. Así que, un map es solo un objeto elegante. Y así, básicamente, lo que quiero es tener un nuevo conjunto para cada clave que, para cada clave.

Así que, obviamente, necesitamos una manera de obtener la clave. Por el momento, hagamos algo sucio y hagamos esto. Recorremos cada clave de keys. Y luego, si el suscriptor no tiene una clave, creamos un nuevo conjunto para él. Y luego, hacemos const depth es igual a subscribers.getKey, así. Así que, obtenemos el conjunto de suscriptores. Y ahora, solo podemos hacer depth.add la función. Así que, añadimos la función a este array.

Podemos eliminar esto y básicamente podemos hacer lo mismo para limpiar todo. Así que, podemos eliminar todo esto. Obtenemos la dependencia y hacemos delete function. Así que, realmente necesitamos eso. Está bien. Así que, básicamente, ahora, necesitamos actualizar nuestro código de una manera aún más fea porque ahora necesitamos especificar manualmente nuestra suscripción. Así que, necesito hacer checked. Estoy interesado en checked y estoy interesado en count aquí. Para esto, solo estoy interesado en checked. Y para esto, solo estoy interesado en value.

Ahora, si hice todo correctamente y digo, oh, necesito hacer algo más. Necesito cambiar esto para que sea la clave. Así que, necesito obtener el suscriptor de esa clave específica. Y dado que esto puede ser null, hagamos esto también. Para que estemos seguros. Y ahora, no está funcionando. Así que, creo que... Ah. Está bien. Oh, en ambos lugares, obviamente. Está bien. Ahora, si guardo, esto debería funcionar igual.

Y así, si hago clic, está ejecutándose. Si lo marco, está ejecutándose. La parte agradable, sin embargo, es que ahora puedo cambiar esto y la reactividad sigue funcionando, pero no estoy ejecutando ese código innecesariamente. Ahora, obviamente, como el DX de esto. Comencé esta charla diciendo, está bien, podemos tener un mejor DX, y esto es en realidad mucho peor. Entonces, lo que realmente quiero es que si leo algo en una función, quiero que esa cosa sea una dependencia de esa función.

Ahora, si has usado Svelte 5 un poco, introdujimos runes, que utilizan señales bajo el capó. Y cuando declaras estado, lo declaras así, $state. Y luego, si usas algo como la función $effect, donde pasas una función, así que si usas una función... Si usas una variable con estado dentro de una función pasada dentro del efecto, entonces todo lo que lees será en realidad una dependencia de eso. Y en realidad podemos hacer eso, porque lo exploramos antes, pero podemos hacer get.

Y así, podemos saber cuándo leemos algo. Así que, podemos hacer target, key, así. Podemos devolver target en key. Y luego, básicamente, ese es el punto donde podemos suscribirnos. Así que, en lugar de hacerlo aquí al principio, podemos hacerlo aquí. Así que, si el suscriptor no tiene la clave que estamos buscando, creamos un nuevo conjunto. Obtenemos la dependencia, y luego añadimos la función a la dependencia. Ahora, ¿cuál es la función? Bueno, en JavaScript, no hay API para saber en qué función estás ejecutándote. Pero dado que queremos esta API, en realidad podemos engañarlo, porque una función es solo una variable.

Así que, puedo hacer let current effect es igual a null. Y luego, aquí puedo hacer current effect es igual a función. Y luego, puedo invocar la función, y luego puedo volver a establecer current effect a null. Y esto significa que cuando estoy ejecutando esta función, si leo algo, esta función será invocada. Y puedo verificar si current effect está definido para saber en qué función estoy ejecutándome.

Así que, puedo decir si current effect, entonces haré este tipo de cosas. Así que, hago esto, y obviamente, necesito renombrar función a current effect. Y obviamente, ahora, necesitamos cambiar nuestro código de nuevo, porque no necesitamos devolver subscribe más. Solo podemos devolver el proxy, que es una API mucho más agradable. Pero necesitamos cambiar un par de cosas. Necesitamos cambiar cada subscribe que necesita convertirse en signo de dólar effect. Y obviamente, necesitamos eliminar esto.

Así que, si guardo, ahora, todo debería funcionar bien. Si reviso, y está funcionando. Si reviso, está funcionando. Y eso es todo. No, eso no es todo. Hay un error aún. Porque si ahora aumento el contador, no está funcionando. Y si desmarco, y vuelvo a marcar, entonces se actualiza. Y la razón de esto es porque dentro de nuestro efecto, estamos estableciendo current effect a función, y luego ejecutamos la función, y luego establecemos current effect de nuevo a null. Pero esto significa que cuando leemos el valor, la segunda vez que esta función se ejecuta, no establecemos current effect antes de ejecutar la función.

Esto, sin embargo, es en realidad muy simple, porque podemos hacer función efecto actual, y envolvemos todo este código dentro de este efecto actual. Lo invocamos la primera vez. Pero luego el efecto actual se convierte en efecto actual en lugar de función. Así que, esto significa que ahora, cada vez que volvemos a ejecutar la función, así que, en este caso, si aumentamos una dependencia, entonces verificamos, y ahora count es una dependencia. Porque antes de ejecutar la función que actualiza count, en realidad actualizamos el efecto actual a efecto actual.

Eso es todo. Aún no. Porque si desmarcamos, ahora, todavía tenemos una dependencia en count. Lo cual es un poco extraño, porque no estamos leyendo count la segunda vez. La UI no está cambiando. Así que, la razón es que estamos añadiendo algo al conjunto de suscriptores, pero nunca eliminamos algo del conjunto de suscriptores.

Sin embargo, dado que cada vez que ejecutamos el efecto, exploramos una rama, en realidad podemos, antes de ejecutar el efecto, eliminar ese efecto de la dependencia de cada clave que tiene ese efecto como una dependencia. Es un poco complicado, lo sé. Pero en realidad es muy fácil de hacer. Podemos hacer profundidad es igual a un nuevo conjunto. Así que, este es el conjunto de todos los conjuntos que contienen efecto como una dependencia. Y en lugar de solo pasar el objeto, podemos pasar profundidad y la función así. Así que, ahora, cuando añadimos la dependencia, añadimos la función aquí, y luego hacemos efecto actual punto profundidad punto añadir profundidad. Así que, estamos añadiendo este conjunto de suscriptores a la dependencia de este efecto. Y ahora, lo que podemos hacer es, antes de ejecutarlo, podemos iterar sobre let de profundidad... lo siento. Podemos hacer let profundidad de profundidad así. Y podemos hacer profundidad punto eliminar efecto actual.

También podemos limpiar el conjunto solo por si acaso. Y ahora, si guardamos, esto debería funcionar bien. Y si hacemos clic aquí, no estamos obteniendo ejecuciones adicionales. Y cuando revisamos, ya no tenemos una dependencia en count. Y podemos hacerlo. Y podemos hacer clic en ello y hacer clic en ello y cosas así.

Aún queda un error. Si hago esto, state dot value es igual a JS Nation. Y si guardo, en el momento en que escribo algo aquí, se congela. No puedo escribir más. La razón de esto es porque hasta este momento, nuestros efectos son sincrónicos. Lo que significa que para cuando llegas a esta línea aquí, este código aquí en el efecto ya se ejecutó.

Lo que significa que cuando estableces state dot value a JS Nation, este input dot value se ejecuta antes de este state dot value. Y así, establecemos input dot value a JS Nation. Y luego establecemos state dot value al input dot value. Para solucionar esto, también porque es muy ineficiente, como si básicamente estuviéramos ejecutando el código dos veces aquí donde no necesitamos ejecutar el código dos veces.

Podemos implementar un agrupamiento muy básico. Lo que significa que podemos hacer const to run es igual a un nuevo� adivinaste� un nuevo conjunto. Y luego podemos hacer función schedule. Y dentro de este schedule, si to run dot size es mayor que cero, entonces sabemos que ya hemos programado algo y simplemente podemos regresar. Y luego podemos encolar una microtarea, lo que significa que irá a la siguiente microtarea. Y luego podemos recorrer cada función para ejecutar e invocarla. Y al final, podemos limpiar to run. Y ahora necesitamos actualizar esto para que podamos programar cada vez.

Y luego, en lugar de llamar a la función inmediatamente, simplemente añadimos la función a la cola. Y si guardo, esto está funcionando, esto está funcionando. Y funciona. No está volviendo a ejecutar el código innecesariamente. Y eso es todo.

Ahora, esto, obviamente, es mucho más complejo en Svelte. Así que, si vas a Svelte, en el repositorio de Svelte y tratas de buscar este código, no habrá tal cosa en este código. Porque en Svelte, es mucho más complejo porque necesitamos lidiar con transiciones y animaciones que tienen sus propios problemas. También hay la situación de escritura que no estoy explorando. Sin embargo, esto es la implementación más básica de cómo funcionan las señales. Así que, si sabes esto, puedes prácticamente resolver cualquier problema de reactividad que estés teniendo. Y esto no está relacionado solo con Svelte. Como, si estás usando un framework basado en señales, que es bastante común hoy en día, con este modelo mental de cómo funcionan las señales, puedes resolver problemas de reactividad. Por ejemplo, muchas personas están algo confundidas por el hecho de que count no es una dependencia inicialmente. Ahora sabes por qué. Porque para obtener una dependencia, realmente necesitas leer ese código. Otra cosa que confunde a la gente es cuando hago await 42, y si hago async aquí y guardo, esto en realidad deja de funcionar. Y la razón de esto es muy simple. Si tienes una función async, después del primer await, esto se ejecuta en la siguiente microtarea, lo que significa que dado que estamos haciendo esto aquí, estamos estableciendo el efecto actual, estamos invocando la función de manera sincrónica y luego la estamos estableciendo de nuevo en null. Para cuando leas el checked y leas count, el efecto actual ya estará null. Así que, estas son las cosas que confunden a la gente cuando piensan en el efecto, sobre las señales. Y con este modelo mental muy básico, ahora puedes averiguar por qué está sucediendo, por qué está sucediendo algo.

Si estás interesado, el código está en github.com. Ahí está el código inicial y luego el código final. Y si tienes alguna pregunta, estoy aquí para eso. Gracias.

Veo una pregunta ahora. ¿Cómo almacenarías los datos? Esto fue al principio de tu presentación, así que piensa en lo que dijiste al principio. ¿Cómo almacenarías los datos si ocurre una recarga de página al usar este concepto de almacenamiento local de sesión o usando un almacén diferente? Sí, puedes usar almacenamiento local en general. Esto es algo que creo que muchos coautores de frameworks realmente desaconsejan, y es el hecho de que, como, las personas a menudo dependen de efectos para hacer este tipo de cosas. Pero muy a menudo, no es necesario. Como, efectivamente, lo que puedes hacer es, como, si quieres almacenar dentro del almacenamiento local, por ejemplo, podrías usar un efecto para sincronizar. Y eso es realmente decente de hacer. Pero lo peor que puedes hacer es reasignar el estado dentro de un efecto. Y así, cada vez que hagas, como, lo que yo haría probablemente sería crear un envoltorio alrededor de esto para que cada vez que establezcas el estado, en lugar de hacerlo en un efecto secundario, en la misma línea, puedas establecer el estado y luego también almacenarlo en el almacenamiento local. Así que, si haces algo como esto, como, el código está mucho más contenido. Es mucho más, ¿cómo puedo decirlo? Como, una línea después de la otra, puedes ver claramente lo que estás haciendo. Estás estableciendo el estado y almacenando el valor en el almacenamiento local. Y es mucho más fácil de razonar en lugar de, oh, si cambio este valor, un efecto en el otro lado del proyecto, lo siento, el laboratorio que estaba en el otro lado del proyecto está cambiando. Claramente, ese era el otro lado del proyecto. Genial.

Gracias. ¿Puedes describir uno de los escenarios complejos más importantes que Svelte tuvo que manejar en la implementación de señales? Así que, si preguntas sobre, como, cuál es la parte compleja del sistema de reactividad basado en señales de Svelte, diría que es el derivado desconocido. Así que, el problema con las señales es que generalmente siempre tienes que limpiar tu memoria. Así que, obviamente, no profundicé en esto dentro de esta presentación, pero generalmente, lo que cada framework de señales hace es crear un efecto raíz que es más eficiente en memoria que el efecto normal y almacenas, como, básicamente, usas eso como un punto de entrada para que al final de la página, ese efecto sea responsable de limpiar todos los efectos que creas porque de lo contrario, tendrías un montón de memoria, como, simplemente dejada ahí. Y el problema es, como, en Svelte, por ejemplo, mientras estés dentro del componente, ese componente puede manejar la memoria de las señales que creas dentro de él. Pero en Svelte 5, también puedes crear señales solo en un módulo y un derivado que se crea dentro de un módulo, se llama un derivado desconocido porque, obviamente, vas a usar ese derivado en todas partes de tu aplicación, así que no en un componente específico. Así que, esto significa que, como, necesitamos hacer todo tipo de, como, para realmente limpiar, como, para evitar fugas de memoria con el derivado desconocido. Así que, esa es la parte más compleja de la implementación basada en señales. Entendido. Gracias.

Pensé, como, ¿cuál es la parte más compleja de implementar cualquier cosa? Es, como, trabajar con otros y asegurarse de que algo suceda. ¿La implementación quedará obsoleta después de la propuesta de TC39 para señales, si eso pasa? Así que, si esa implementación es mi implementación, sí, probablemente. La razón es que, como, si las señales de TC39, como, entran en la plataforma web, tendrás básicamente esta, como, gestión de dependencias y cosas así integradas en la plataforma. Sin embargo, esa implementación en realidad no viene con un efecto. Y la razón de esto es porque, como he dicho, los efectos son muy específicos para cada framework, lo que significa que necesitarás implementar tu propio efecto para hacerlo realmente, como, operable con tu framework. Así que, como, todavía necesitas implementar la parte del efecto, que es más simple tal vez. Pero, así que, sí, esta implementación definitivamente puede desaparecer y puedes simplemente implementar un rápido efecto. Frameworks, esta es una de las cosas de las que soy más escéptico sobre la implementación de TC39 es que mucha gente piensa que eso desbloqueará la creatividad entre frameworks. No creo que eso sea cierto porque lo más probable es que cada framework aún necesite construir sobre esa propuesta para luego integrarse correctamente con el framework en sí. Muy bien. Hubo otra pregunta que era muy similar y simplemente la archivé. Sentí que fue respondida. Espero que estés de acuerdo conmigo y, de lo contrario, ya sabes, no estás en el escenario. Estoy en el escenario.

Yo hago las reglas. Entonces, ¿qué requisitos previos hay para empezar a trabajar con señales, en tu opinión? No creo que haya un requisito previo. Como, diría que las señales se están volviendo muy populares. Pero para ser justos, son un poco de una obstrucción con fugas porque, como, si sabes cómo funcionan, y esa es básicamente la razón por la que hice esta charla, como, si sabes cómo funcionan, puedes trabajar mejor con ellas. Así que, si tienes este modelo mental de, está bien, solo es establecer, como, almacenar la función que estoy ejecutando actualmente dentro de un conjunto y luego hacer que, como, vuelva a ejecutar esa función cuando cambia. Si tienes este modelo mental, es muy fácil entender por qué algo no está funcionando como piensas. Pero, sí. No creo que haya un alto techo, especialmente en Svelte porque en Svelte, bueno, como, tú básicamente los tratas como variables normales. Así que, mientras que, por ejemplo, en Solid, que es súper genial, pero uno de los problemas de Solid es que tienes que llamar a una función porque si lees un valor en JavaScript, eso es todo. Como, lo has leído y no puedes hacer nada al respecto. Así que, en Solid, siempre tienes que llamar a funciones para mantener viva la reactividad.

En Svelte, es menos problemático porque podemos llamar a la función por ti con el compilador. Muy bien.

Gracias. Veamos. ¿Hay una solución para el problema asíncrono o es esta una limitación para las señales? La solución es Svelte. No. Sé que sueno como un disco rayado. Pero en realidad hay una nueva propuesta en Svelte que está en una rama experimental por el momento que desbloqueó la capacidad de usar un sync dentro de un componente Svelte. Y estamos haciendo un poco de trabajo de compilador para que funcione. Pero, sí, hasta hoy, básicamente no hay forma de obtener algo después de el primer await. Otra solución que Solid estaba a punto de implementar era, como, simplemente leer todos los valores inicialmente. Así que, básicamente tienes un array de dependencias igual que en React. Lees cada señal y luego todas las cosas se pasan en una segunda parte del efecto. Así que, básicamente no puedes esperar todo porque, como, la primera parte, que es sincrónica, ya leyó todos los valores. Muy bien. Muchas gracias. Dejaré a todos en el rincón de preguntas y respuestas contigo si tienen más preguntas. Gracias de nuevo, Paolo, por tu tiempo. Gracias. Gracias por tu tiempo. Gracias.