Estandarización de Señales en TC39

Hablaré sobre la estandarización de señales en TC39. Para presentarme, me hago llamar LittleDan en internet en Bloomberg. He estado trabajando en TC39, el Comité de Estándares de JavaScript, desde 2016. Y algunas de las cosas más grandes en las que trabajo incluyen BigInt, los enteros de tamaño arbitrario que tienes en JavaScript, y Private usando el hashtag. Hace un par de años, me mudé de la costa de Cataluña, donde puedes ver la pequeña costa de mi pueblo. Tiene una forma como de ir a un punto. Y ahora, la oscura ciudad de Nueva York.

Así que el terminal de Bloomberg es, mi trabajo es trabajar en eso, y los estándares están, ya sabes, relacionados con eso. El terminal de Bloomberg es una gran suite de aplicaciones que está basada en Chromium por dentro. Así que es un poco como una aplicación electron. Y entonces el frontend está escrito generalmente en JavaScript. Y por eso es realmente importante para nosotros impulsar el lenguaje JavaScript, así como HTML y CSS, todas las tecnologías web. Así que volviendo a lo básico de por qué señales, pensemos en por qué usamos frameworks de UI. Así que el modelo antiguo, que tal vez muchos de ustedes no estén familiarizados, era PHP en el servidor, o algo diferente en el servidor, que tiene tu plantillado, luego envías algo al cliente, y eso tiene un pequeño script de JavaScript en él, tal vez con jQuery o tal vez solo JavaScript puro. Y generalmente, el modelo era, tienes una forma de hacer la forma inicial en que tu página se renderiza, y luego haces correcciones más tarde en el cliente. Y uno de los patrones era el estado en el DOM. Tengo un ejemplo en la siguiente diapositiva. Y el nuevo modelo con React y sus descendientes, como todos los frameworks modernos, siguen este modelo donde haces el plantillado de la misma manera para renderizados iniciales frente a renderizados posteriores, y el estado en lugar de estar atrapado en el DOM o variables globales aleatorias, puede centralizarse con un flujo de datos unidireccional.

Así que aquí hay un ejemplo simple. En el modelo antiguo, podrías tener una página con un botón y contador, así que este tipo de ejemplo enlatado de reactividad. Es muy simple con el vanilla.html a la izquierda, hacer que tengas un botón, y cada vez que lo haces clic, obtienes el contenido del span, lo incrementas, y lo escribes de nuevo en el mismo lugar. Se ve muy conciso y limpio. Pero el problema con esto es, si necesitas hacer algo más complicado cuando el estado cambia, por ejemplo, persistir el hecho de que el contador incrementó en el servidor, ahora tienes que estar reaccionando a los cambios en el contenido del texto. Porque el estado está simplemente distribuido en el DOM, se vuelve realmente complicado organizar tus cálculos posteriores. Por otro lado, en React, puedes crear tu estado por separado, y tu plantilla puede basarse en ese estado, así que el span incluye el conteo. Nunca actualizas el span directamente, actualizas el conteo, y luego eso se refleja. Esto permite diferentes tipos de usos de eso, y diferentes cálculos dependientes. Esto es lo que las señales facilitan resolver. Así que, el trabajo clave de los frameworks de UI es mantener el DOM actualizado con los datos. Eso te permite separar los datos del DOM, y luego, ya sabes, el framework lo vuelve a poner.

Una forma de hablar sobre esto usando palabras antiguas es que la vista es una función pura del modelo. Tal vez hayas oído hablar del modelo vista controlador, y no sepas qué significa. Esta es una forma antigua de hablar sobre la vista siendo la UI, el modelo siendo una especie de datos debajo de ella. Esto se aplica completamente al paradigma de React, si lo piensas de esta manera.

Así que, eventualmente, todos llegaron a un punto común en los frameworks. Si miras hace diez años, había mucha diversidad en cómo manejar esta situación de plantillado. Pero en este punto, la mayoría de los frameworks tienen este concepto de señales. Y React tiene un modelo de programación similar donde todavía basas todo lo que haces en lo que quieres que la cosa final se vea, y lo haces como una función de eso. Hay diferentes algoritmos para alcanzar eso, pero en última instancia es el mismo tipo de modelo de función pura.

Así que, una vez que tienes tu interfaz de usuario como una función del estado, hay múltiples formas de intentar evaluar eso. El modo inmediato es cada vez que algo cambia, borras toda la pantalla, y escribes una cosa completamente nueva. Así que, estos son términos usados en el pasado en el desarrollo de juegos. El modo retenido es diferente. En el modo retenido, no estás describiendo cómo se pinta toda la pantalla. Cuando alguna parte del estado cambia, averiguas exactamente qué cambiar en la UI para obtener el resultado correcto. Así que, eso es un poco más como mi ejemplo de vanilla JS antes. Lo que obtienes con la reactividad basada en señales es un comportamiento de modo inmediato con el rendimiento de modo retenido. Así que, el modelo de programación es que describes cómo el modelo, cómo el estado de los datos se convierte en la vista, el DOM. Pero cuando realmente se ejecuta, solo actualiza lo que es necesario. Y solo si es necesario. Incluso solo hace los cálculos si son necesarios. Así que, este es también el modelo de programación de React.

Por eso digo que todos están un poco en el mismo punto aquí. Las señales representan una celda de datos que puede cambiar con el tiempo. Así que, tienes una celda base mutable llamada estado, que puedes crear, obtener o establecer valores, y luego un cálculo derivado en caché llamado señal computada, que se crea pasando una función, y luego tienes una forma de obtener el valor de ella. Estas son las APIs utilizadas en la propuesta de señal estándar. Mostraré algunos ejemplos más tarde. Pero hablemos de cómo funcionan. Hay mucho comportamiento común a través de los frameworks actuales.

Uno es el seguimiento automático. Cuando tienes una señal computada, observa en ese callback que le pasas qué señales se leen. Y esas se convierten en dependencias que son rastreadas automáticamente en el gráfico de dependencias de señales. Luego, cuando una de esas dependencias cambia, se invalidan automáticamente. Así que, entonces sabe que no puede almacenar en caché el valor computado. En última instancia, los computeds son como use memo. Son una caché. Las señales también se evalúan de manera perezosa. Así que, cuando tienes una señal de estado que es utilizada por una señal computada y el estado cambia, el computado no se recalcula inmediatamente. En su lugar, las señales computadas solo se evalúan cuando se leen, no cuando una de sus dependencias se actualiza. Esto es realmente importante para, bueno, por un lado, para un cierto nivel de anti-rebote, pero también para evitar este problema llamado el problema del glitch que explicaré en un minuto. Y estas cosas juntas crean esta propiedad de consistencia desde cero. Siempre que estés usando funciones puras en tus computeds, todo funciona igual que si reevaluara todo desde cero.

Entonces, el problema del glitch es si implementas señales de manera ingenua, donde cuando tienes un estado y lo cambias, eso vuelve a ejecutar el computado, ya sabes, así es como funcionaba mucha de la generación anterior de frameworks. Cuando React salió, su innovación, bueno, una gran parte de su valor fue que no hacía esto. Solo evaluaba las cosas cuando eran necesarias. Pero anteriormente, ya sabes, AngularJS y Ember, cuando algo cambiaba, determinaba, ok, tengo las cosas que dependen de ello, así que actualizaré esas, y eso se convierte en un lío.

En particular, si estableces una señal, y luego tienes algún efecto que se basa en reaccionar a ese cambio de señal, podrías observar estados intermedios de la computación. Entonces, en este caso, t.get siempre debería ser mayor que seconds.get, porque es uno más que él. Pero si hay una búsqueda que va a la izquierda antes de ir a la derecha, al visitar las actualizaciones, podría registrar falso porque podría ver uno de ellos actualizado y el otro no actualizado. Y esta imagen es del gran artículo de Wikipedia sobre reactividad.

Entonces, la solución es un poco complicada, pero históricamente, los frameworks intentaron, ya sabes, implementar partes de esto, y en este punto, todos se dan cuenta, no, solo tenemos que hacer la solución correcta, que es ordenar topológicamente las dependencias y evaluarlas en un orden coherente. Entonces, este es un gráfico acíclico dirigido, si hay un ciclo, eso puede causar un error cuando se crea el ciclo. Así que, eso se puede detectar. Pero puedes ordenar los nodos para que nunca estés ejecutando un computado antes de que todas sus cosas que vinieron antes ya hayan sido ejecutadas. Y la evaluación basada en extracción también es crucial para esto. Porque haces este orden cuando ocurre un get. Hay múltiples algoritmos para evaluar esto. Este es un post de blog de Kristen, anteriormente del equipo de EmberJS, sobre el uso de números de revisión. Otro algoritmo, esta es una explicación de Milo del equipo de Solid, es usar este tipo de empuje hacia adelante de la suciedad y luego reevaluar nodos basados en eso. De todos modos, no tengo tiempo hoy para entrar en los algoritmos. Pero aunque hay múltiples algoritmos, tienen el mismo comportamiento observable. Hacen lo mismo, ejecutan el computado en el mismo orden.

Y en última instancia, lo que ha sucedido con los frameworks, se puede comparar con la carnicización. Entonces, el fenómeno donde un montón de diferentes animales todos tuvieron evolución convergente hacia el plan corporal de un cangrejo. Porque para ciertos estilos de vida, es muy efectivo. Y creo que hemos visto eso dentro de los frameworks de JavaScript. No es como si Solid inventara señales y todos las copiaran. Históricamente, otros frameworks estaban un poco acercándose desde otros lados y viendo diferentes piezas del problema y todos han influenciado entre sí directamente y también han resuelto el mismo problema y llegado al mismo lugar.

Entonces, cuando en Bloomberg estamos pensando en cómo queremos construir nuestro front end, qué tipo de framework usar, bueno, hasta ahora, nuestro desarrollo de software se ha basado en gran medida en estándares. Como dije, el terminal principal se basa en Chromium. Así que, HTML, CSS, JavaScript.

Establecer un estándar a nivel de empresa es bueno, pero es aún mejor si tienes un estándar que sea común para todos. Eso realmente asegura que estos sistemas sean duraderos y estables. Así que, estamos trabajando en esto en ECMA TC39. ECMA es un organismo de estándares con sede en Ginebra, que gobierna varios grupos diferentes. Y TC39 es el 39º comité técnico de ECMA. Y trabajé con Jatin de Google y del equipo de Wiz y Yehuda Katz de EmberJS, trabajando en Heroku, en la presentación de esto a TC39. Pero en realidad, esto fue precedido por meses de trabajo con muchos diferentes proveedores de frameworks para, ya sabes, mantenedores de frameworks para idear una API que pudiera respaldar sus varios conceptos de reactividad. Y esto se implementa en un polyfill que puedes usar.

Lo que hicimos fue envolver las señales de Angular en esta API, que es solo una superficie de API ligeramente diferente, y la hicimos de código abierto. Y puedes probarlo. Recomendaría probar las señales, las señales de TC39 en una rama de desarrollo, porque todavía están en una etapa temprana. Así que, por ejemplo, puedes simplemente obtenerlo en NPM. Y el beneficio de esto es que las señales estándar significan que podemos compartir código entre frameworks. Que podemos construir infraestructura común que pueda ser reutilizada.

Así que, a nivel de aplicación, si estás usando estas señales de una manera que se implementa en varios frameworks, podríamos tener una estructura de datos reactiva, que es independiente del framework. Esto solo representa los datos y la forma en que se calculan a partir de sí mismos. Así que, si tienes una interfaz de usuario con un contador que puedes incrementar, pero en este caso, también está mostrando si el contador es par o impar, de una manera que está un poco en caché. Este es un ejemplo simple, pero si esos dos cálculos fueran costosos, podría tener sentido almacenarlos en caché. Y luego podría usarse en diferentes frameworks, como React o Vue.js, simplemente accediendo a ese modelo.

Y la forma en que esto funciona es porque estos getters, llaman al punto get, y a través de el seguimiento automático, notará que hay una dependencia. Así que, el framework tiene que integrarse solo un poco para asegurarse de que al evaluar estas expresiones, se conectará al sistema de señales para reaccionar cuando algo cambie. Así que, para facilitar el uso de señales, hemos desarrollado una infraestructura común que podría ser reutilizada en diferentes lugares. El repositorio de signal utils es uno donde, por ejemplo, podrías tener decoradores para tener un campo de una clase que reacciona basado en señales. Y esto está usando los nuevos decoradores de etapa 3 de TC39. Así que, puedes decorar campos privados también. Además, si quieres tener un objeto que sea reactivo, como la función reactiva de view, esta función de objeto de señal hace que tengas un proxy alrededor de un objeto, para que todo acceso sea mediado por señales. Así que, cuando lo incluyes en una plantilla, simplemente causará el mismo seguimiento automático. Las señales no tienen que ser usadas directamente en la expresión, siempre que en algún lugar profundo en la pila de llamadas, se esté accediendo a ella. Así que, puedes usar signal utils en NPM. Pero aunque es posible adoptar señales directamente, en este futuro potencial donde tenemos señales estándar, las aplicaciones no necesitarían cambiar.

Y eso es porque la API de signal está diseñada para ser envuelta por diferentes frameworks. No es especialmente bonita de usar por sí sola. Pero hasta ahora, es nuestra mejor suposición actual de lo que funcionaría eficientemente cuando otras cosas se superponen, como signal utils, pero también como la forma en que otros frameworks funcionan.

La idea es que las APIs de frameworks existentes usarían signals internamente. Una integración que ha tenido lugar recientemente es Lit, siendo un framework basado en componentes web. Y otra integración fue en Ember. Así que, esta persona, Life Art, la integró, encontró errores en el polyfill de signal, errores significativos. Este error fue corregido. Pero en general, tenemos mucho por hacer. Así que, diría que este cangrejo está cocido, cansado. Aún no hemos terminado. Podemos seguir adelante, pero necesitamos tu ayuda.

Así que, por favor, únete al esfuerzo. Tenemos una sala de chat pública a la que puedes unirte y reuniones regulares cada dos semanas para discutir la evolución de signals. Probar experimentalmente usando esta biblioteca de signals y reportar tu experiencia sería realmente útil. Así que, ha habido algunas integraciones experimentales tempranas en frameworks, pero realmente necesitamos probar eso más para ver qué tan bien funciona. Y en aplicaciones. También puedes presentar problemas o comentar en hilos de GitHub o unirte a ECMA en TC309. Así que, por favor, ven a hablar conmigo si quieres involucrarte. Podemos mantenernos en contacto en BlueSky. Estoy en littledan.dev o por correo electrónico. Y en Bloomberg, estamos contratando. Así que, por favor, puedes venir al stand que tenemos al lado, obtener algunos regalos allí, y también mirar nuestro sitio web de empleos. Así que, gracias a todos.

**BEN HONG:] Quiero decir que lo primero es, esto es súper emocionante para mí. Como, lo que imagino es poder escribir lógica de negocio agnóstica al framework.

**JASON LENGSTORF** Sí.

**BEN HONG** Y luego puedes usarla en un framework o compartirla a través de eso. Así que, no es una pregunta, pero eso me emociona. Esta idea de poder compartir código sin ser específico de un framework.

**JASON LENGSTORF** Me alegra que te guste la idea. Creo que esto es lo que los estándares pueden lograr. Más portabilidad, menos necesidad de tomar decisiones para encerrarte en un ecosistema u otro. Podemos ver esto en otros lugares, como con los módulos ES que tienen cada vez menos configuración con el tiempo, menos y menos configuración para las herramientas de construcción, en parte debido a cómo estamos evolucionando el sistema de módulos para llenar vacíos de características. Eso es lo que espero lograr con los Signals.

**BEN HONG** De hecho. Y creo que podrías haber mencionado en qué etapa está esto, y, como, ¿qué sigue o qué se necesitaría para llevarlo a esa etapa?

**JASON LENGSTORF** Olvidé mencionarlo.

**BEN HONG** Está bien.

**JASON LENGSTORF** Sí. Esta propuesta está en la etapa 1. Es una propuesta muy temprana. TC39 no ha acordado que queremos seguir adelante con ella. Solo está sobre la mesa para discusión.

**BEN HONG** Está bien. Y supongo que en ese punto, mucha gente se pregunta, como, ¿debería ser esto una cosa? Y, sí, así que la pregunta actual que tenemos de Andrew es, ¿por qué debería ser un estándar de lenguaje? Parece muy específico de navegador o UI y no aplicable al back end. Así que supongo que, sí, estoy imaginando usarlo en un front end con un framework de front-end. Pero si está en el estándar, eso es algo que también usan los motores. Así que ¿puedes hablar sobre cómo se usaría allí? ¿Por qué tiene sentido estar en el estándar?

**JASON LENGSTORF** Así que creo que hay dos preguntas aquí. Una pregunta es, ¿tiene sentido estar en los navegadores? Y otra pregunta es, ¿tiene sentido estar en el lenguaje? ¿Tiene sentido estar en los navegadores? Creo que es muy útil en diferentes frameworks de UI. Así que hay todo tipo de características que están en los navegadores que no son útiles fuera de los navegadores. En cuanto a por qué debería estar en el lenguaje en sí, no sería el fin del mundo, en mi opinión, si decidiéramos que esto debería ser un estándar de navegador en lugar de un estándar de JavaScript. Pero es útil fuera de los sitios web. Por ejemplo, los signals son parte de los sistemas de construcción modernos. Los algoritmos subyacentes a los signals para calcular el menor número de reconstrucciones que tienen que suceder.

Además, implementar una característica en el motor de JavaScript a menudo hace posible optimizar aún más solo basado en cómo están arquitectados los navegadores. No es 100% necesario que lo que está en los navegadores corresponda a o lo siento, lo que está en el motor de JavaScript corresponda a la especificación de JavaScript. Pero históricamente así se ha hecho. Así que creo que será importante optimizar bien esta característica en implementaciones reales.

**JASON LENGSTORF** Interesante de ver. Porque supongo que no lo hace el lenguaje, entonces tal vez sea un estándar de navegador. Incluso entonces, podría simplemente quedarse como un polyfill. Podría imaginar construir algo sobre esto y simplemente ser como independientemente de si se admite, podría seguir usándolo.

**JASON LENGSTORF** Sí. Podría. Quiero decir, el paquete NPM actual no es lo suficientemente estable como para que eso sea una buena idea. Pero hay problemas reales con, por ejemplo, NPM terminando duplicando paquetes. El seguimiento automático depende de esta variable global, que es lo que es el signal actual. Tienes que poder añadir a esa lista cuando encuentras una dependencia. Así que si la biblioteca de signals se duplica, has roto la compatibilidad. De hecho, hay un par de otras variables globales que los frameworks tienden a usar, como el tipo actual de propietario o componente que también son realmente esenciales. Así que no es, esto podría no ser el final de la historia. O tal vez simplemente mejoraremos como ecosistema en gestionar y eliminar las duplicaciones. Sí, veremos.

**JASON LENGSTORF** Quiero decir, ¿es eso algo que ponerlo en el lenguaje o el navegador potencialmente solucionaría? Como algo que- **JASON LENGSTORF** Solucionaría el problema particular de la variable global. Creo que podría ser más optimizable en los navegadores por un factor constante. Podría ser un poco más rápido.

No va a ser como asintóticamente más rápido ni nada. **JASON LENGSTORF** Bien. Este siguiente es de Y. Dice, en la evaluación basada en pool, ¿cómo saben los pullers que el valor puede haber cambiado y deberían extraer el valor de nuevo? **JASON LENGSTORF** Evaluación basada en pool. Oh, evaluación basada en pull.

Así que hay una parte de esta interfaz que no mostré llamada watcher, que es un conjunto de signals, que podrían ser signals de estado o calculados, que están siendo actualmente observados. Y la idea de la API es que hay un callback sincrónico que se realiza cuando el primer miembro de ese conjunto se vuelve potencialmente sucio debido a algo que apunta a que su estado cambie. Así que cuando eso ocurre, puedes luego programar la lectura de esos signals. Una cosa importante es que no permitimos que leas sincrónicamente esos signals durante ese callback, porque termina causando el mismo problema de glitch que mencioné al principio.

mencioné al principio. **JASON LENGSTORF** Entiendo. Esta siguiente, creo, es solo una especie de pregunta general sobre cómo esto podría relacionarse con bibliotecas en React. Así que esto es de Balaji, quien dice, ¿es un sustituto o está cerca de los gestores de estado, como Imr para React? Y entonces Imr es la biblioteca de estado inmutable que a menudo se usa con React. Entonces, ¿ves esto siendo usado junto con bibliotecas como esa o cualquier otra biblioteca de gestión de estado? **JASON LENGSTORF** Creo que las bibliotecas de gestión de estado son realmente importantes, y los signals son como el equivalente de useState y useMemo.

Y a veces podrías simplemente usar eso directamente, pero a menudo quieres centralizar tu gestión de estado en algún lugar por varias razones diferentes. Por ejemplo, para el enrutamiento, esa es una forma más básica de gestión de estado central que determina, que impulsa toda la ejecución. Así que creo que estas cosas deberían componerse bien, aunque pueden implementarse un poco diferente. En ambos Redux y signals, hay conceptos como selectores para Redux para hacer que no reevalúes demasiadas cosas cuando nada cambió. Y los signals también tienen eso, pero implementado un poco diferente.

Sí, ese es exactamente el ejercicio que me gustaría hacer durante esta etapa temprana de la evaluación con la propuesta en la etapa uno. Así que si alguien está buscando un proyecto de código abierto, simplemente tome cualquier herramienta de gestión de estado que le guste y vea si funciona para portarla a signals. Y podrías unirte a nuestro Discord para charlar con nosotros y obtener ideas o comentarios.

**JASON LENGSTORF** Eso es genial. Probablemente voy a hacer eso, honestamente. Esta siguiente es de Vladimir. En realidad no sé cuál es la pregunta. Tal vez puedas averiguarlo. Así que Vladimir dice, WebSockets, MQTT, que es como una cosa de cola de mensajería escalada, signals.

**JASON LENGSTORF** Así que tengo una idea de de qué podría tratarse. Quiero decir, los signals solo existen en una máquina. No cruzan una red. Pero puedes poner signals en ambos lados y conectarlos a través de WebSockets. Así que esto es potencialmente algo prometedor. Hay cierta complejidad en torno a signals y async. Quiero decir, gran parte del trabajo que se está haciendo en Solid 2.0 es sobre eso. Y sería genial si la gente experimentara más con eso. Es una característica muy solicitada. No va a ser parte de la propuesta incorporada.

**JASON LENGSTORF** Genial. Sí, supongo que no pensé en eso. Pero sí, ¿y si pudieras sincronizar dos navegadores a través de signals y luego tienes esta agradable API de signals, pero detrás de escena, está comunicándose en tiempo real a través de WebSockets o algo así?

**JASON LENGSTORF** Sí, esa es la idea. Quiero decir, los signals son una abstracción y puedes ocultar diferentes cosas detrás de ellos. Así que podría ser eventualmente tal vez un estándar web, pero no sería un estándar TC39, porque no hacemos ninguna red en el lenguaje JavaScript.

**JASON LENGSTORF** Correcto. Veamos. Un par más están llegando. Y adelante, voten por las preguntas si ven alguna para que sepa cuáles les gustaría ver. Elegiremos la que esté en la parte superior aquí. Así que considerando que la propuesta recomienda a los motores dejar muchas cosas a los autores de frameworks para implementar, ¿por qué no unirse en torno a un paquete de usuario?

**JASON LENGSTORF** Podríamos hacer eso.

Veremos cómo va. Creo que, como mencioné antes, existe este problema de la variable global, y también está el potencial para una mayor optimización. Además, creo que el propio proceso de estándares a veces ayuda a que las cosas se unan en un ecosistema. Así que, sí, no lo sé. Veremos si ese es un posible resultado de este proceso.

**JASON LENGSTORF** Genial. Y hay una pregunta aquí. Es como, ¿cómo funciona todo esto? Mencionaste que estás en el comité TC39. Así que están preguntando, ¿qué se necesita para unirse al comité TC39?

**JASON LENGSTORF** Oh, está bien. Así que TC39 está abierto para miembros. Para convertirse en miembro de ECMA, se hace a nivel organizacional. Y para universidades o entidades sin fines de lucro, como la OpenJS Foundation, puedes unirte gratis. También invitamos a expertos a venir gratis. Para las empresas, hay ciertas tarifas de membresía. En todos los casos, tienes que firmar un contrato legal particular para asegurarte de que estás licenciando las cosas que contribuyes antes del estándar, como un CLA, excepto más fuerte.

**JASON LENGSTORF** Así que si estás interesado en unirte al comité, por favor ponte en contacto conmigo. **JASON LENGSTORF** Genial. Muy bien. Eso es todo el tiempo que tenemos para preguntas aquí. Pero si tienes más preguntas, si te diriges a la sala de cristal, puedes hacer más preguntas allí. Pero sí, muchas gracias. Vamos a dar otro aplauso para Daniel. Gracias, Daniel. Lo aprecio.