Casi todos son gratis, ¿vale?
Pero vamos a hablar de esto, el tema de useState.
Ya sabrás, y esto no necesita saber React,
porque es algo que también pasa en algunos otros frameworks,
bibliotecas, ¿no?
El tema del useState.
Bueno, ha habido un tuit muy interesante de Misco,
en el que estoy de acuerdo, además,
que habla de que useState va a morir, básicamente,
que es una mala abstracción y que el useSignal
es una mejor abstracción que useState.
Entonces, vamos a ver por qué lo es,
qué es el useSignal y por qué creo que tiene razón.
Y me parece muy interesante porque si esto realmente llegase a React,
¡buah!
¡Buah!
De forma nativa, que yo creo que va a llegar, ¿eh?
Creo que va a llegar.
Te falta el que es useState.
A ver, useState es un custom hook.
Perdón, es un hook, no un custom hook.
Es un hook para añadir estado a un componente en React.
Por ejemplo, cuando las luces, si están encendidas o apagadas,
eso es un estado que tiene la habitación.
Y si está encendida, pues ve la luz encendida, si está apagada,
ve la luz apagada.
Lo mismo puedes pensar con el botón me gusta y todo esto.
Bueno, eso es el useState.
¿Pero qué pasa con el useState?
Es de React, pero lo tenemos en otras bibliotecas.
Por ejemplo, lo tiene Preact.
Este concepto lo pueden tener otros frameworks,
como puede ser Mithril, como puede ser Lit.
O sea, Lit también tiene un state.
O sea, pensate en este concepto que va más allá de React.
No es una cosa solo que le pasa a React.
Este concepto, por ejemplo, también lo tendía...
Ah, pensaba que tenía que el state.
Ah, es que tiene reactive properties.
No, lifeCycle.
Pensaba que tenía estado.
Ah, pues pensaba que Lit tenía state.
Me lo he imaginado.
Ah, no, state.
Sí, sí, sí.
Vale, state, state.
Vale.
Entonces, el useState, el state, el estado,
solid creo que lo tiene...
Creo que el state de solid funciona diferente, ¿no?
El tema es que un montón de bibliotecas,
un montón de bibliotecas tienen este concepto de tener estado.
Que el estado, cada vez que cambia,
se vuelva a renderizar todo el elemento, ¿vale?
Entonces, ¿qué pasa?
Que habla de useSignal.
Y entonces vamos a entender exactamente qué es esto de useSignal.
Una cosa que ya vimos en su día de PRIAC,
que lo había añadido, que funciona con React también.
Y vais a ver lo potente que es.
De tanto esfuerzo y de tanto mover las manitas,
las cosas solo pueden ponerse mejor.
Muchas felicidades, Midu.
Midu, wink, Midu, voz.
Midu, wink.
Muchas gracias, Edgar.
Vale.
Pues, entonces, ¿qué es el useSignal?
Como dice por aquí, es el futuro de los frameworks web.
Y es una mejor abstracción que useState.
Que ya está haciendo...
Está un poco viejo.
Está viejo porque es verdad que el useState a la hora de optimizar
nuestros componentes es bastante peor.
Funciona bastante peor.
Entonces, aquí tiene esta imagen que dice useState más uREF más
useMemo menos renderizados constantes igual useSignal.
Esto para que os hagáis un poco un modelo mental de lo que sería
el useSignal.
El useSignal sería tener estado en tus componentes,
pero de una forma mucho más focalizada.
En lugar de hacer que todo tu componente se re-renderice entero,
de que sea todo el render, que eso lo podéis ver muy fácil.
A ver, a ver si tengo por aquí...
Vamos a ver projects.
0, 1.
Ah, mira, justo qué bien que tenemos aquí.
Oye, estamos haciendo un montón de proyectos ya con nuestro curso
de React.
Mira, en este ejemplo lo vais a ver muy claro.
Porque aquí en el 1, por ejemplo, aquí esto no tiene...
Vale, aquí sí que tiene...
¿Veis?
Aquí tiene...
Vale, aquí tenemos un estado.
UseState.
Y ves este console.log que pone TwitterFollowCart renderWithUsername.
Claro, si os fijáis, si le doy aquí, esto, este console.log que se ha ejecutado ya
diez veces es este de aquí.
¿Y qué es lo que está pasando aquí?
Lo que está pasando aquí es que se está ejecutando este código,
pero también se está ejecutando este de aquí, esto de aquí.
Se está volviendo a crear este método.
Se está renderizando todo esto.
Lo que por suerte...
Y esto es lo realmente interesante.
Porque React tiene el Virtual DOM.
Y el Virtual DOM lo que hace es evitar como un coste mayor, ¿no?
Porque fijaos que lo único que hace es lo que cambia, realmente lo cambia.
Pero lo demás solo cambia.
Este span, este texto, esta clase.
Y todo lo demás lo deja igual.
Porque si te fijas, este dejar de seguir no cambia.
Entonces, gracias al Virtual DOM, digamos que este problema va a menor.
O sea, lo mitiga.
El Virtual DOM, toda la estructura del Virtual DOM es para mitigar el hecho de que cada vez que tú cambias el estado,
claro, se renderiza todo esto.
O sea, se ejecuta y se evalúa todo esto.
Todo, todo, todo.
Todo.
Es increíble.
Lo que pasa...
Cara sonriente.
Cara sonriente.
Gracias, hombre.
Claro.
Entonces, lo que hace el Virtual DOM es evitar el coste de esto, ¿vale?
Pero fíjate, fíjate en una cosa.
Veremos el certificado en las web.
Hecho a mano moviendo las manitas.
Qué grande.
Ya te digo, Noel.
Vale.
Pues entonces, el tema es...
El tema es que como todo esto se evalúa, esto tiene un coste.
Y es innecesario porque ya hemos visto que justamente lo único que cambia es esta parte de aquí.
Entonces, justamente el useSignal lo que viene a hacer es justamente el único cambio.
Aquí veríamos cómo puedes crear tu propio useSignal, ¿no?
Aquí dices, useStare requires esta useRef indirection.
Claro, para evitar que haga todo esto que hemos hecho aquí,
si quisiéramos memorizar todo y tal, fíjate todo lo que tendríamos que hacer.
En cambio, con el useSignal, que sería este de aquí, solo tendríamos que hacer esta línea de aquí.
Que cada vez que lo queramos actualizar, tendríamos que hacer count.value y cambiarlo.
Y fíjate que además no tienes que llamar al setState, sino que lo hace directamente.
Utilizas para todos los overlays, alertas, etcétera de los directos.
Utilizo streamElements, creo que lo decía...
Es decir, ¿más magia aún?
Vale, buena pregunta, ¿no?
Porque Belted dice que sí es más magia.
Pero si lo ves fríamente, ¿qué es más mágico?
¿Qué ves que es más mágico?
¿En el estado acceder al value y cambiar el valor o tener que llamar a un método?
La verdad es que es un poco similar.
No lo veo como uno más mágico que el otro, ¿no?
Lo veo al final una forma diferente de hacerlo.
Solo que en este tienes que llamar a un método que has tenido que sacar de aquí.
O sea, con magia, ¿no? Es una abstracción.
Y luego aquí, pues lo único que tienes que hacer es actualizar el valor con el punto value.
Entonces, la diferencia mental que tenemos aquí es que el useState lo que haces es tener la lectura del valor y el setter.
Pero en el useSignal tienes un getter y un setter.
Y al getter y al setter siempre tendrías que acceder a través del punto value.
O sea, sería un getter y un setter.
El primero parece más vanilla.
Claro, es que cada uno tendrá una opinión, ¿no?
Unos dirán que te parece más vanilla, otro que no, otro que no.
O sea, que está interesante por eso.
Básicamente te ahorra la función de leer mucho más métodos y hace corta la compilación del mismo.
Claro, es que además, luego aparte de esto tienes la ventaja de la mejora en rendimiento.
Y ahora vais a ver por qué, ¿no?
Mira, ¿qué es lo que hace aquí?
Porque aquí está haciendo que las señales hacen que el renderizado sea mucho más eficiente.
En el caso de las señales, que es este ejemplo de aquí, fíjate que lo único que necesita, detecta que cada vez que cambia, lo único que va a cambiar es esto.
Y esto lo hace sin virtual DOM.
Que esto es lo que lo hace interesante.
Porque sin virtual DOM lo que dice es, vale, lo único que cambia es esta parte de aquí.
Pues sin virtual DOM ha como encapsulado el componente, la parte del componente que cambia y dice, vale, pues lo único que cambia es esta parte.
En cambio, con el useState, ¿qué es lo que pasa?
Cuando cambia el estado, re-renderiza todo este counter, lo re-renderiza.
¿Veis? Aquí lo tenemos en rojo.
Y además también todo el hijo.
Y el hijo tiene este componente que también es otro hijo y entonces finalmente esto.
O sea, son como dos cosas diferentes.
Porque lo que está haciendo aquí es una actualización mucho más quirúrgica y la de la derecha es una actualización encascada.
¿Sabes?
Obviamente, y lo peor es que esto tiene un coste brutal.
Fíjate en este ejemplo.
Fijaos en este ejemplo.
Que mira que esto es un ejemplo sencillo.
Esto es un ejemplo sencillo.
Y fijaos todo lo que ha tenido que actualizar.
Aquí te dice.
Dice, mira, le tengo que actualizar todo este componente.
Que claro, es un milisegundo.
Pero imaginad, ¿ves?
Y cada vez que lo he ido actualizando, pues aquí vemos que se ha actualizado.
Y que se ha actualizado todo.
Pero imaginad que sea una lista de elementos.
Es que es espectacular.
Mira, seguro que en Fotocasa tienen problemas con esto.
Vamos a verlo.
Vamos a verlo.
Siempre se me ocurre en Fotocasa, ¿eh?
Pero, hostia, hostia, cuánto rojo, Dios mío.
Cuánto rojo.
Vamos a ver aquí Profiler, ¿vale?
¡Ay!
No nos deja hacer Profiler.
No está soportado.
Porque, claro, es que solo es en desarrollo.
¡Qué lástima!
Lo hubiéramos hecho.
Pero, bueno, hubiéramos visto que a lo mejor cuando hacemos esto,
este cambio de estado se pone a actualizar un montón de cosas.
Y esto hace como una actualización en cascada muy bestia, ¿sabes?
En cambio, con las señales, lo que veis es que solo cambia esa parte que necesita.
A Fotocasa le hemos pegado con el carrito de ese lado.
¡Qué bueno!
Mira, aquí tenemos un ejemplo, ¿no?
Lo bueno de este ejemplo es que puedes tener más de una señal que sería algo diferente a las estados, ¿no?
Tienes dos señales.
Y de forma quirúrgica, cada señal que cambia es la que va a actualizar esto.
¿Sabes?
O sea, vas a hacer que, aunque tengas dos señales, cada vez que cambies una de las dos señales,
lo único que cambia es este del que cambie.
Eso es brutal.
Es brutal.
Te facilita quitar los useMemo, useCallbacks y useMemo.
Claro, lo que nos facilita es que cuando tengamos que optimizar nuestros componentes de React,
digamos que nuestros componentes de React están optimizados por defecto.
Ahí está.
Nuestros componentes de React están actualizados por defectos.
Me gusta más el estilo de Svelte.
Claro, Svelte, Svelte, como es un compilador, hace un poquito de trampa.
Pero es algo muy parecido, ¿no?
En realidad Svelte sería algo similar a esto.
De hecho, lo podemos ver.
Si nos vamos a Svelte, a mí me encanta Svelte porque al final lo que tú escribes es lo que es.
Pero, por ejemplo, reactividad, ¿no?
Esto sería el ejemplo de Svelte.
En Svelte lo que vemos aquí es que es totalmente transparente.
O sea, es totalmente transparente, ¿no?
Así que le damos aquí al Output.
A ver.
Uy, no me sale el Output.
Hola, Output.
No sale el Output.
Ah, que está cargando el Compiler.
¿Me está cargando el Compiler o...?
Ah, sí.
Parece que sí.
Está haciendo el Fetching.
Vale, vamos a ver si funciona o no funciona.
Porque, joder, cómo tarda, Dios mío.
Que está descargando aquí.
Se está descargando la vida, Dios mío.
A ver si aquí funciona.
Nada.
Pero, ¿qué pasa?
Svelte.
Ah, mira, ya.
Vale, si miramos el...
Iba a decir, si miramos el Output, pero ¿y el Output?
No hay Output.
No hay Output.
A ver, un momento.
Output.
Vale, aquí sí que sale.
Debe ser que se cree que es un anuncio o algo.
Vale, si veis el Output, vais a ver que está utilizando en realidad...
¿Ves?
Esto es lo que compila Svelte.
Tú escribes este código y a la derecha os sale este.
O sea, claro, ahí es donde está el truco, el almendruco.
Pero, ¿ves?
Fijaos que return C lo que está haciendo es encapsular estas partes en unos métodos.
Fíjate que el click está en el método text.
Y esto lo que hace es justamente que es capaz de detectar cuando cambia.
Porque este T3 value, pues aquí tiene.
T3 value cambia cuando pasa esto.
Mira, a ver si encontramos...
Ta, ta, ta.
¿Ves?
Mounted.
Dirty set data.
Aquí es donde está haciendo la magia del estado.
Ta, ta.
¿Ves?
Y todo esto lo está haciendo con observables.
Básicamente está observando cada vez que hay un cambio.
Y cuando ejecutas el handle click, que es lo que actualiza el estado,
estás llamando al invalidate.
Que esto sería como llamar a un método para actualizar la señal.
Y le dice, vale, la señal tienes que actualizarlo con esto.
¿Vale?
Invalidate.
Y este invalidate lo que hace es volver a renderizar todo, no todo el componente,
porque este invalidate también internamente hace que sea como más granular.
Porque detecta exactamente dónde está el cambio.
Y esto debe ser pues este.
El T3 value este debe ser que lo saca del invalidate.
T3 value.
¿Ves?
Aquí tenemos dirty, no sé qué.
Si cambia esto, entonces hace esto y no sé qué.
Así es como lo hace.
Esa es la magia potagia.
¿Qué tal la compatibilidad del signal con los navegadores?
No es un tema de compatibilidad al final.
Es un tema de que el framework lo haga.
Es como el use state.
No es un tema de compatibilidad con los navegadores.
Es que el framework lo haga.
De hecho, yo creo que React, de hecho, estoy bastante de acuerdo,
que creo que React lo va a añadir.
Creo que va a añadir el use signal porque tiene bastante sentido.
Mira, lo tiene ya Quick, SolidJS, Vue.
Bueno, Vue le llama ShallowRef y Preact.
Son los cuatro frameworks que a día de hoy ya están utilizando algo muy parecido de este use signal.
Es una cosa que es bastante antigua.
O sea, el concepto es bastante antiguo porque ya se utilizaba en su día en otros frameworks y tal.
Pero es verdad que el use state, cuando lo comparas con esta solución, pues no es lo mejor.
Yo, ya sabéis que Signal lo tenemos en Preact.
¿Ves?
Tiene esto que se llama Signals.
Y esta librería la podéis utilizar también en React.
¿Pero qué pasa?
Que es una biblioteca externa, que no es nativa de la propia biblioteca.
Esto lo que sería genial es que lo añadiesen en React como un custom hook suyo propio.
Eso es lo que yo creo que sería tremendo porque obviamente tienen la posibilidad
de darle un soporte mucho más potente.
¿Podríamos implementarlo en algún momento?
A ver, implementarlo utilizando la biblioteca esta sería bastante fácil.
Sí, Lightoff en Twilio.
Ostras, sí.
Madre mía, qué pena.
Twilio eran nuestros patrocinadores el año pasado y este año no.
Este año no.
Twilio ha despedido a 1.500 empleados, al 17% de su plantilla.
Pero es que lo más fuerte es que en septiembre ya había echado al 10%, me parece.
En septiembre echó a 9%.