Voy a hablaros de JavaScript.
JavaScript es el lenguaje de programación maravilloso que siempre tiene cositas que añadir porque JavaScript no para de evolucionar.
Y una de las cositas que se está hablando, amigos y amigas, es la propuesta de los signals, las señales.
Ojo con esto, tiene pintaza porque esta propuesta lo que busca es añadir un primitivo, que sean las señales, en JavaScript.
¿Qué quiere decir esto?
Bueno, pues igual que tenemos promesas, igual que tenemos diferentes cositas en el lenguaje que nos ayudan a trabajar o con asincronía o con estados, con lo que sea.
La idea del JavaScript signals sería tener una propuesta para estandarizar también las señales.
¿Y para qué sirven las señales?
Pues básicamente las señales lo que nos sirven es como para poder actualizar estados, poder observarlos y tratar y responder a esos cambios.
Y esto nos simplifica un montón la vida porque lo que estamos haciendo es traer básicamente una interfaz para tratar la reactividad en JavaScript de forma nativa sin dependencias.
¿Por qué?
Porque a día de hoy, queramos o no, para tratar cambios de estado tenemos que escribir cierto código en JavaScript que puede ser un poco tedioso.
Poder se puede hacer, obviamente.
Por eso muchas bibliotecas lo traen, React, Angular, Vue, un montón, traen reactividad.
Pero tenemos que escribir mucho código.
Pues lo que viene a traer esto de las signas es que podamos tener un código mucho más sencillo, mucho más fácil que este.
Fijaos, esto sería un contador de JavaScript donde tenemos un contador y cada vez que hacemos el setCounter, aquí lo que hacemos es que cada segundo estaríamos actualizando el counter.
El problema de esto, pues que hay que llamar al render cada vez que queremos actualizarlo.
Bueno, no pasa nada, pero sí que tenemos ahí unas dependencias, aquí lo dicen un poquito, ¿no?
Tenemos el estado que está acoplado, tenemos que llamar nosotros al render, no es declarativo, es como muy imperativo, ¿no?
Con las señales lo que tendríamos, fijaos, estaríamos creando un estado, podríamos computar valores a través de ese estado,
y podríamos incluso tener efectos para detectar que cada vez que hay un cambio en ese contador,
pues lo que vamos a hacer es que cada vez que haya un cambio, lo que vamos a hacer aquí es actualizar la UI.
Fijaos la diferencia, qué maravilla, porque tenéis aquí el estado, aquí podéis calcular cambios cada vez que cambie el contador,
podéis ir cambiando si es true o false el hecho que sea par o impar,
y luego tendríamos como un efecto de forma que en lugar de necesitar nosotros llamar al render,
detectamos cuando cambia el valor del contador y entonces actualizamos la UI.
O sea, esto sería increíble, esto sería increíble.
Os digo que el effect no es parte de la API, tendrías que escribirlo tú, pero sería muy poco código, ¿vale?
Entonces, ¿cuál es la motivación de esta pedazo de propuesta?
Interoperabilidad, ¿por qué?
Porque hay muchas bibliotecas de JavaScript a día de hoy que están compartiendo la misma lógica
y que lo están haciendo constantemente, o sea, tanto Vue, como Svelte, como Angular,
hay un montón de bibliotecas que están utilizando la reactividad y la están reescribiendo constantemente.
Entonces, en lugar de tener que estar en todos los sitios escribiendo toda esta lógica
para hacer este tracking del valor de una variable, la idea sería justamente esto, ¿no?
Evitar este modelo reactivo que cada uno lo tenga inventado de una forma y hacerlo todos de la misma, ¿no?
También, obviamente, esto traería mejoras de rendimiento y de memoria,
porque en lugar de tener que llevarlo al lenguaje de JavaScript,
esto lo tendríamos en una implementación más a nivel de C++,
donde tendríamos estructuras de datos mucho más óptimas
y no solo desde JavaScript tendríamos acceso a esta API, que tendría muchos beneficios.
Además, es muy fácil de crear un polyfill,
así que por ahora podríamos hacer que los navegadores que no lo soporten,
que carguen el polyfill y ya está.
Y finalmente también tendríamos unas buenas herramientas de desarrollo,
porque el problema que tenemos ahora con las bibliotecas de JavaScript,
con su propia solución,
es que es muy difícil poder tracear los errores o problemas que tenemos en la reactividad.
En cambio, con esto lo que podríamos empezar es a tener incluso,
igual que tenemos con las promesas, que tenemos unas herramientas de desarrollo muy buenas,
pues podríamos tener incluso una pestaña que fuese Signals para detectar todo esto.
O sea, sería genial, ¿no?
Aquí lo van comentando más,
las integraciones futuras que podríamos tener a nivel del DOM y todo esto.
Así que me parece una propuesta brutal,
que tiene un montón, un montón de sentido,
y que como esto llegue a JavaScript,
va a ser tremendo, ¿eh?
Va a ser tremendo.
Pero esto ya lo hacía Python.
Bueno, puede ser que le dices de Python,
pero me da igual, sinceramente.
Mira, aquí tenemos el ejemplo de crear un watcher,
como para observar.
Esto muchas veces sería a nivel de biblioteca, ¿vale?
No sería que lo haríamos nosotros.
Esto estaría más a nivel de biblioteca,
por ejemplo, haría React, haría el suyo propio,
Vuear haría el suyo propio.
Pero imaginad esto,
que son muy pocas líneas de código.
O sea, son muy, muy pocas líneas de código,
que no tiene nada que ver a cómo lo están haciendo ahora, ¿no?
Hay alguna demo, me parece,
si no me equivoco, había por aquí,
hay código con demos.
Lo digo por si os interesa.
Mira, incluso ya están haciéndolas el polyfill y todo esto.
A ver, example.
Por ahora, obviamente,
obviamente, imaginad que esto está muy verde, ¿eh?
O sea, esto está muy, muy, muy verde.
Así que no penséis o no esperéis
que esto va a llegar la semana que viene,
ni nada de esto.
Esto es muy a largo plazo,
seguramente estamos hablando,
cuando incluso puede ser que un año,
dos años o más,
o más, hay que darle tiempo.
Pero quién sabe,
igual si se alinean los astros,
puede ser que se hagan cosas buenas de esto
y sea mucho más rápido de lo que esperamos.
porque ya en el TC39,
que es el comité que se reúne
para hablar de estas propuestas,
fijaos que en la agenda
tiene cosas muy interesantes,
pero han añadido los signals.
O sea,
van a hablar ya de los signals.
Justamente,
no sé si era hoy o mañana,
en la reunión que van a tener del TC39,
el comité que es para evolucionar JavaScript,
lo van a tener en la agenda
y van a hablar ya de la propuesta.
La propuesta está en fase cero,
o sea,
totalmente experimental,
puede cambiar la API,
puede cambiar el nombre,
pueden cambiar muchas cosas,
o sea,
que todavía está muy verde,
pero solo para que lo sepáis,
que sí que van a hablar,
van a hablar ya de los signals,
o sea,
que es una cosa que están teniendo en cuenta.
Y hay otras cositas
que además,
tienen muy buena pinta
en el mundo de JavaScript,
porque uno,
van a hablar de los récords y las tuplas.
Los récords y las tuplas,
por si no lo sabéis,
es una propuesta
que viene a traer
dos nuevos tipos de datos
primitivos en JavaScript,
las tuplas y los récords.
¿Qué serían?
Los récords serían como
un objeto inmutable y profundo
y las tuplas,
un array inmutable y profundo.
Que esto,
esto también va a ser brutal
cuando lo traigan.
Lo malo,
pues que todavía está en fase 2,
parece ser que todavía cuesta
que se mueva,
pero esto va a cambiar totalmente
el cómo trabajamos con JavaScript,
porque fijaos la diferencia,
por ejemplo,
para que nos hagamos un poco la idea
y lo veáis claro.
Fijaos en este lock,
¿veis?
Podéis comparar
un récord
y un récord
incluso aunque sea profundo.
O sea,
podréis hacer algo así,
podréis hacer C1,
¿vale?
Y esta igualdad
te va a dar true,
cosa que con los objetos
no podéis hacerlo,
obviamente.
Y esto tendría
un montón
de mejoras de rendimiento.
Si esto lo intentáis comparar
con los objetos,
por ejemplo,
¿veis?
Aquí me está dando true
porque es un récord,
porque son inmutables.
Con un objeto
esto no lo podéis hacer,
un objeto,
esto da false.
Pues de esto también van a hablar
y otra cosa muy interesante
de la que van a estar hablando
es el pattern matching.
No se lo van a hablar,
sino que la idea
es que suba,
suba de fase,
o sea,
que nos estamos acercando también.
Y el pattern matching
de JavaScript,
porque a día de hoy
todavía no lo tenemos,
sería una alternativa
funcional del switch.
Que fijaos,
ahora mismo está ya
en fase 1,
pasaría a fase 2,
o sea,
que ya estaríamos
mejorando la fase
y nos estaríamos acercando
a tenerlo más cerca.
No sé por qué no aparecen
aquí los ejemplos,
pero antes sí que aparecían
antes los ejemplos,
a ver si lo...
Pero esta sería un poco la idea.
Esta sería un poco la idea.
Machear,
aquí tendríamos
como la respuesta
cuando pasa esto,
entonces lo de la derecha,
¿no?
Es algo parecido
al que vimos con PHP
el otro día,
en el curso de PHP,
pero un poquito más...
Con un léxico
como más legible.
Es un poco raro,
la verdad,
porque a mí
no me termina
de convencer
la sintaxis.
Yo espero que la cambien,
no me termina
de convencer
de toda la sintaxis.
Me gustaría una...
Me gustaría más
una sintaxis diferente,
pero bueno.
Sería el match
que mostraste el otro día
en PHP,
sería la idea de eso,
pero la sintaxis
es algo diferente.
No es exactamente igual,
pero sí que la idea
sería exactamente esa.
No es exactamente igual.