Estandarización de Señales en TC39

Rate this content
Bookmark

Los frameworks web modernos trabajan con un flujo de datos unidireccional. Lo que se muestra en la pantalla es una función del estado de la aplicación, y las actualizaciones a ese estado solo actualizan la parte particular del DOM a la que se refiere. A través de sus propios caminos, muchos otros frameworks web han llegado a soluciones que son análogas entre sí, a menudo llamadas "Señales". Ahora, un grupo de autores de bibliotecas de señales y mantenedores de frameworks de front-end están trabajando juntos en TC39 para estandarizar algunas de las estructuras de datos y algoritmos centrales que serán necesarios para las implementaciones de JS de Señales, y podríamos usar su ayuda para impulsar JavaScript hacia adelante.

This talk has been presented at JSNation US 2024, check out the latest edition of this JavaScript Conference.

Daniel Ehrenberg
Daniel Ehrenberg
29 min
18 Nov, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Hablaré sobre la estandarización de señales en TC39. El modo inmediato borra toda la pantalla y escribe una nueva, mientras que el modo retenido solo cambia lo que es necesario. Las señales representan una celda de datos que puede cambiar con el tiempo. La solución correcta es ordenar topológicamente las dependencias y evaluarlas en un orden coherente. Las señales estándar permiten compartir código entre frameworks y la creación de infraestructura reutilizable. La API de señales está diseñada para ser envuelta por diferentes frameworks. Los estándares pueden lograr más portabilidad y reducir la necesidad de encerrarse en ecosistemas específicos. La API incluye un observador, un conjunto de señales que se están observando, con una devolución de llamada sincrónica realizada cuando el primer miembro se vuelve potencialmente sucio. El orador discute cómo las señales se relacionan con las bibliotecas de gestión de estado en React y menciona el potencial de que las señales se conviertan en un estándar web en el futuro.
Available in English: Standardizing Signals in TC39

1. Introduction to Signal Standardization

Short description:

Hablaré sobre la estandarización de señales en TC39. Trabajo en BigInt y Private usando el hashtag. Me mudé de la costa de Cataluña a la ciudad de Nueva York. El terminal de Bloomberg es una gran suite de aplicaciones.

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.

2. Understanding Signal-based Reactivity

Short description:

La vista es una función pura del modelo, lo cual se aplica al paradigma de React. La mayoría de los frameworks tienen el concepto de señales. El modo inmediato borra toda la pantalla y escribe una nueva, mientras que el modo retenido cambia solo lo necesario. La reactividad basada en señales combina el comportamiento del modo inmediato con el rendimiento del modo retenido. Las señales representan una celda de datos que puede cambiar con el tiempo. Hay patrones de comportamiento comunes en los frameworks, como el seguimiento automático.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

¿Futuras características de JS?!
JSNation 2022JSNation 2022
28 min
¿Futuras características de JS?!
Top Content
Welcome to the future features of JavaScript, including proposals for array operations, throw expressions, records and TPUs, pipeline operators, and more. The talk covers the introduction of type assertions for imported files, non-mutating array operations, and the simplification of error handling. It also explores the concept of immutability with records and TPUs, and the use of the pipeline operator to simplify code. Other proposals include Map.implace, IteratorHelper, slice notation, type annotations, Array UNIQBY, number ranges, and the Function 1 proposal.
ES?.next()
JSNation Live 2021JSNation Live 2021
31 min
ES?.next()
The Talk discusses various proposals for the next version of ECMAScript (ES Next) and the TC39 process. It covers features such as binding syntax, shorthand property assignments, pattern matching, async match, operator overloading, and more. These proposals aim to simplify code, make it more readable, and introduce new functionalities. The Talk also addresses questions about the committee's decision-making process and the experience of being part of the TC39 committee.
ESNext: Propuestas a tener en cuenta
JSNation Live 2020JSNation Live 2020
9 min
ESNext: Propuestas a tener en cuenta
ES Next proposal stages include straw person, proposal, draft, candidate, and finished. Optional chaining and null coalescing operators are solutions for handling undefined and null values. Logical assignment and null coalescing operators are seeking advancement to stage four. Decimal type is introduced to address floating point math issues. Cancellation API and abort control are solutions for canceling promise execution. Pattern matching allows matching the shape of a vector and performing actions based on it.
Temporal: Fechas y Tiempos Modernos en JavaScript
JSNation US 2024JSNation US 2024
22 min
Temporal: Fechas y Tiempos Modernos en JavaScript
I'll speak today about the temporal proposal, which adds modern date and time handling to JavaScript. Temporal is an API that'll be available in browsers soon and will add a built-in library for dates and times, avoiding the need for external libraries like Moment. It offers strong typing with different types for different data, such as calendar dates with or without time. Temporal objects are immutable and designed to work with JavaScript's internationalization facilities. It addresses deficiencies in the global date object and introduces types like instant and plain types for accurate representation of time and dates across time zones. With the old date, representing a date without a time can be problematic, especially in time zones where midnight is skipped due to daylight saving time. Temporal introduces types like plain date, plain time, plain year month, plain month day, and zone date time to accurately represent different scenarios. Additionally, there is a type called duration for arithmetic operations and unit conversion. Now that I've introduced you to the cast of characters in temporal, it's time to show how to accomplish a programming task. We'll start with an easy task: getting the current time as a timestamp in milliseconds using the instant type. To convert between Temporal types, you can either drop or add information. The two zone date time method is used for conversion and requires adding a time zone and a time. Although Temporal objects are immutable, you can create new objects with replaced components using the with method. Migrating from the old date object to Temporal offers a more reliable solution and avoids potential bugs. Check out the documentation for more details and enjoy using Temporal in your codebase!