Transiciones lo que te permiten es como separar las actualizaciones de estados en dos cosas.
Una, en las que serían como urgentes, como actualizaciones de estado urgentes,
y en otras que serían como de baja prioridad.
Serían como de, dices, bueno, no es tan importante, no le doy tanta prioridad.
¿Por qué es importante esto? Por ejemplo, no es lo mismo la prioridad que puede tener...
Vamos a intentarlo. Vamos a intentarlo.
Vamos a intentarlo.
Bueno, si ponemos aquí un input, input, type, text, value, set, ¿cómo le he puesto? setInput.
Bueno, este sería el input, onChange, la e, setInput, targetValue, y esto es así, ¿vale?
Y vamos a poner aquí un playholder, input, es decir, algo, venga, vale, ahí tenemos un input.
Voy a quitar esto.
Vamos a poner aquí que empieza a guardar, bla, bla, bla, quitamos, ¿vale?
Tenemos aquí todos los renderizados de cada vez que le he dado una letra, ¿vale?
Y ponemos aquí inmediato, inmediato, inmediato, inmediato, inmediato, ¿vale?
Vamos aquí al Package.json.
Y ya nos vamos a fijar en una cosa, ¿no?
Voy a hacer esto, voy a hacer un reload, start profiling,
voy a escribir una AAA, voy a parar.
Y vamos a ver aquí la prioridad.
Teníamos la primera, que era el cambio del render, del setState, de la respuesta y todo esto.
Fíjate que me pone normal, ¿no?
Normal, normal, y luego le he dado a la A y me pone inmediato, inmediato, inmediato.
Esto es porque RIAC ahora, de una forma como más inteligente,
lo que va a intentar es decir, bueno, ¿cuáles son las autorizaciones de estado que tienen más importancia, ¿vale?
Por supuesto, el input, imagínate la experiencia del usuario.
Cuando tú detectas que lo que vas a autorizar es el estado del input,
tú quieres que eso ocurra de la forma más inmediata posible
y que la UI se refleje cuanto antes.
Porque, claro, queda muy raro, queda muy raro tú estar escribiendo y que no responda.
Entonces, en este caso, lo que podemos ver es que responde súper rápido, ¿vale?
Y lo hace a costa de decir que esto tiene prioridad inmediata.
Pero, en cambio, hay otras cosas que a lo mejor dices, bueno, pero esto no es tan importante.
Y si quieres llevarlo al otro nivel ya, porque ya vemos que puede diferenciar entre normal e inmediata,
podemos ver aquí que ahora tiene una nueva cosa que se llaman transiciones.
Las transiciones, lo que te permite es básicamente decirle lo que es urgente,
lo que sería urgente, pues lo dejaríamos fuera, ¿no?
Sería un setState como los que ya hacemos ahora, pero también podemos hacer una transición.
Que esto lo que quiere decir es marcar esa actualización del estado como algo que ya no es tan importante.
Por ejemplo, mostrar los resultados.
¿Qué quiere decir esto?
Pues que yo ahora aquí en el código, aquí podemos ver que tengo un startTransition,
podríamos hacer aquí esto.
Bueno, podríamos importar este startTransition.
Vale, no sé por qué no me ha hecho el...
No me lo está pillando.
No me lo está pillando.
No sé por qué no me sale la os...
No me sale la definición.
Me preocupa, me preocupa.
Me preocupa.
Por cierto, he actualizado...
Sí, sí.
No, iba a decir he actualizado RIA18, pero sí.
Vale.
StartTransition.
Lo que le podemos decir, por ejemplo, es que todo esto lo vamos a poner aquí dentro.
Vamos a decir, no, es que esto que ocurra no es tan importante como cuando actualizamos el input.
¿Vale?
O sea, el setInput lo dejamos normal, pero esto es una transición.
Esto lo podemos hacer para cosas de UI, para transiciones, como dice el nombre,
pero no os quedéis con el nombre de transiciones como las animaciones que hacemos,
que lo podría ser.
Por ejemplo, cuando navegamos de una página a otra, eso puede ser una transición.
Pero también pueden ser para cambios del estado que a lo mejor no tienen tanta prioridad.
Puede ser mostrar una notificación en un sitio, cosas que ya no sean tan importantes.
¿Vale?
O sea, eso es lo que realmente sería importante.
Pensar que las transiciones son actualizaciones del estado que sabemos que no son prioritarias
para la experiencia del usuario.
¿Vale?
¿No te parece un poco confuso el nombre?
¿Puede ser?
¿Puede ser?
Mira, transiciones are interruptible.
No bloquean el input del usuario y mantienen tu aplicación responsive.
Es verdad que puede ser un poco raro porque la gente puede pensar que una transición
es básicamente una animación, ¿no?
Pero creo que transiciones no es una cosa que se utiliza solo en el mundo de React.
Por ejemplo, en React Router se utiliza como transición,
pero no se refiere a la transición de la animación.
Se refiere a este tipo de transición entre pasar de un estado a otro.
Como que no es tan importante.
Ya, yo pensaba que eran transiciones.
Bueno, al final nos vamos a tener que animar, ¿vale?
Las transiciones vendrían para mejorar la performance de la web.
Más que la performance de la web, sí que va a ser la performance de la web,
pero sería más la experiencia del usuario, ¿no?
No tener la sensación de que tú estás haciendo algo y no se actualiza.
Porque lo que vamos a decirles es, vale, el input tienes una prioridad que es muy alta,
pero a lo mejor el setear la respuesta pues no es tan importante.
Vamos a ver si guardamos esto y le damos aquí.
Y hacemos un restart y le damos aquí.
Bueno, podemos ver que aquí igualmente nos lo está dejando normal.
No sé si, la verdad, viendo esto del start transition que teníamos por aquí,
no sé si en este caso ya lo estaba haciendo por defecto.
¿Por qué?
Porque está detectando que está dentro de un useEffect,
como que al final es una respuesta de una API y ya está como utilizando el start transition.
Porque si os fijáis, lo que son los del input, sin yo necesitar de hacer nada,
ya me está diciendo que era inmediato.
Y en cambio los de la...
La respuesta ya me ha sorprendido que estaba automáticamente diciendo que eran normales.
O sea, que eso me ha...
¿Ves? Normal.
Sin necesidad de utilizar el start transition.
Así que me imagino que más que aquí, a lo mejor es que le tenemos que decir en otro sitio, ¿sabes?
Que en otro sitio sí que tiene más sentido que se lo digamos.
No tanto como respuesta de una llamada a un endpoint.
Puede ser que sea eso.
Porque aquí, por ejemplo, sería para el mismo input.
¿Veis que aquí está utilizando como el mismo input?
Es como diciendo, por ejemplo, set search query.
Claro, en este caso es set input value, sería el input, o sea, es el mismo valor.
Sería como el handle change.
O sea, lo que están haciendo aquí sería como el handle change.
Aquí tendríamos el evento.
Y lo que están haciendo aquí sería algo así.
Sería algo así.
Mira, handle change.
Es como separar.
Lo que están haciendo es separar el estado en dos.
Por un lado tendríamos el set input, que este sería como el importante, digamos.
¿Vale?
El importante.
Vamos a poner prioridad alta para la UI, ¿no?
Y luego tendríamos el de prioridad baja para la UI.
Y tendría aquí como otro estado.
Vamos a llamarle query.
Use state query.
Y aquí lo que está haciendo es set query.
También con el target value.
Y esto lo está haciendo en una transición.
Start transition.
Y esto lo está haciendo aquí.
Y este query sería el que utiliza aquí.
Cada vez que cambia esto, pues lo que está haciendo...
No se puede buscar la pokeapi, un pokémon por el nombre.
Me imagino que no, ¿no?
Ah, sí.
Pokémon.
Y aquí sería el nombre, ¿no?
Pues vamos a poner aquí la query.
Vamos a poner que al principio esto...
Ah, y he puesto aquí query y esto no es así, ¿eh?
Aquí deberíamos poner, por ejemplo, vamos a poner al principio Pikachu.
Pikachu.
Y que luego lo podamos cambiar, ¿vale?
Y esto lo vamos a poner aquí como un template string.
Pa, pa, pa, pa.
Y vamos a volver a nuestra aplicación.
¿Vale?
Tenemos Pikachu.
Y aquí vemos que es Pikachu.
Perfecto.
Lo que vamos a hacer...
Es si yo quito esto y pongo dito, ¿vale?
Y ahora paro aquí.
Vale.
Ahora sí que podemos ver que hay unos que son inmediatos, otros no sé qué.
O sea que son diferentes.
Vamos a ver.
Si yo voy a quitar esto otra vez.
Y aquí pongo p y quito.
Vale.
Inmediato, normal y normal.
Vale.
Aquí podemos ver que tenemos el inmediato.
Que es una pena que no te dice aquí justamente el setState.
O sea, este es el setState que ha hecho esto.
Bueno, lo que ha hecho es que el primer setState, este setState, el inmediato, sería este de aquí, ¿vale?
Este es el primero que ha hecho.
Luego el siguiente que pone normal sería este de aquí.
Y luego, pues básicamente porque ha hecho otro renderizado, porque ha hecho la llamada, la API y todo esto, ¿vale?
Pero bueno, si lo queréis ver más claro, lo que podríamos hacer es quitar todo esto.
Voy a quitar el efecto.
Y vamos a, por ejemplo, volver a buscar.
Pongo una A.
Vale.
Y aquí tenemos la diferencia, ¿vale?
Tenemos uno inmediato y tenemos otro que la prioridad normal.
O sea, que tendríamos que este se ha actualizado rápido, porque ha dicho este, lo tengo que mostrar rápido,
pero este no lo ha actualizado con la misma velocidad.
La verdad es que en este caso, yo la verdad es que no entiendo muy bien, porque total, como hace un automatic batch,
no tiene mucho sentido.
Pero en el ejemplo, en el ejemplo este, justamente, a ver, no en este ejemplo.
Es que en este ejemplo es porque yo lo he forzado como pensando que es lo mismo,
pero a lo mejor está hablando de dos situaciones distintas, de dos componentes distintos, ¿eh?
Pero básicamente sería eso, que no bloquea el input del usuario cuando haces un start transition.
Ya está.
No debería generar conflictos o complicaciones.
Sí, lo hemos comentado.
Lo hemos comentado.
Sí, se supone, claro, si quito este, el problema es que si quito este,
yo lo que me da la sensación es que a lo mejor hace automatic batching, ¿sabes?
Porque al final son dos set states en el mismo sitio y entonces no vamos a ver la diferencia directamente, ¿sabes?
O sea, no creo que veamos la diferencia.
No creo que veamos...
Pues no, también.
What is the update?
Lo vemos igual.
Porque en este caso es como actualizar...
Bueno, claro, el primero es render normal, priority, immediate.
En este caso lo vemos exactamente igual.
No sé si es porque lo está detectando.
Es que no entiendo muy bien este ejemplo, la verdad.
Vamos a ver si lo ponemos aquí, start transition.
You can use it to navigate between scripts.
Ah, bueno.
Ah, bueno, dice, pero por ejemplo.
Pero no dice que sea esto solo, ¿no?
Bueno, igual sí que solo es para transiciones, ¿eh?
Porque, coño, por lo que pone aquí.
Pero es raro, ¿eh?
Porque aquí no pone...
No dice que sea justamente para esto.
Básicamente lo que dice es que son transiciones entre comillas.
Que básicamente que las actualizaciones que están envueltas en start transition
son manejadas como que no son urgentes
y pueden ser interrumpidas en el caso de que haya algo más urgente.
Esto, en este caso, es porque yo me imagino que el set input,
si tú empiezas a escribir aquí,
lo que quiere decir es que si tú empiezas a escribir aquí, así,
ta, ta, ta, ta, ta, ta, ta, ta, ta.
Lo que puede decir es que interrumpe la actualización del otro.
Eso es lo que quiero, me imagino que quiere decir.
O sea, que sería, si tú haces esto,
es la actualización que hace esta,
que a lo mejor puede ser...
No, pero a ver, esto ya sería increíble que petase hasta el efecto,
pero eso no lo va a hacer.
Pero lo que a lo mejor es que este input,
si tú empiezas a escribir aquí como un loco,
que nunca se te va a bloquear,
porque lo que va a estar haciendo es como quitar...
Es como...
Siempre vas a ver, ¿lo ves?
Siempre vas a ver los inmediatos.
Nunca vas a ver el otro, ¿no?
Pero llegará un punto cuando termina que dice,
no, ahora ya que has dejado de escribir,
voy a hacer el que tiene la prioridad normal en algún momento.
Ahora...
Pero veis que hay algunos que pone dos inmediatos de golpe.
Esto es porque he escrito muy rápido
y lo que ha hecho es evitar hacer esta transición.
En algunos casos, que a lo mejor lo he hecho más lento,
ya sí que se ve la transición de la normal.
Básicamente es que está priorizando esto
y está bloqueando el renderizado que haría este.
Eso es lo que estaría haciendo, básicamente.
Esto podría servir para los buscadores
que actualizan el on-change en el input.
Bueno, básicamente está pensado para eso,
para el on-change de los inputs.
Porque muchas veces, no sé si os ha pasado,
pero en Rian muchas veces tú escribías muy rápido
y como esto constantemente estaba haciendo
de los otros set states,
pues se te bloqueaba el input, básicamente.
Y ahí teníamos el problema.
A hook está incluido una value to track
depending state.
Use transition.
Dice...
Y transition gets interrupted by the user.
Mira, por ejemplo,
tipeando múltiples caracteres,
React lo que va a hacer es que va a dejar
en stale el renderizado anterior.
Entonces va a priorizar el del input.
Ahí está.
Vale.
Vale.
Bueno, vamos a seguir con lo siguiente.
Bueno, suspense.
Que esto...
Suspense ya hace tiempo que está.
Este componente para suspender como la UI.
Pero suspense en React 17 solo funcionaba
para hacer un React punto lazy.
O sea, eso es cuando estabas haciendo
un lazy loading de un componente de React.
Entiendo aquí que por lo que dice
hay dos grandes mejoras en React 18.
Una...
Ah, las dos son para server render apps.
¿Vale?
Y estos es porque desbloquea
una sola API de suspense.
En el servidor suspense
se...
Hace progresivamente
lo que hace es streamear el HTML.
Esto, por ejemplo,
lo hará NextGS seguro de gratis
y no nos tenemos que preocupar.
Y luego en el cliente suspense
activa la hidratación selectiva.
¿Esto qué es lo que quiere decir?
Porque la verdad es que visto así
parece un poco complejo.
Pero bueno, con este markup
lo vamos a ver mucho más claro.
Esto lo que quiere decir
es que ahora desde el servidor
vamos a poder renderizar
toda la página.
Toda la página.
Pero imagínate que
necesitamos hacer un fetching de datos
de esta parte de aquí.
Que esto puede ser, yo qué sé,
los comentarios.
Pues lo que va a pasar
es que nos va a devolver
toda la página
y esto lo que va a hacer
es que cuando lo tenga listo
el servidor lo va a devolver
y en el cliente entonces
lo hidratará.
Igual va hidratando
lo que sí que tiene listo
y esto, mientras va cargando,
pues lo deja ahí
y cuando lo tenga
te lo envía.
Esto básicamente es un streaming.
O sea, streaming como lo que hacemos
con los vídeos.
Y esto lo hacen
un montón de páginas ya.
Que lo que te hacen
es ir enviando datos
conforme lo van teniendo.
¿Qué es lo que pasa?
Que a día de hoy,
no siempre,
pero a día de hoy
en muchos casos
lo que se hace con React
es que una vez que lo tienes
todo renderizado
lo envías al cliente.
Y eso es un rollo.
En este caso
pues va a ser muchísimo
más óptimo
y vamos a ver mejoras
de performance brutales
en este caso.
¿Vale?
Y dice,
esto lo que significa
es que, claro,
¿qué es lo que pasaba
hasta ahora?
Que si tú tenías
una API lenta,
imagínate que tú tienes
una API lenta
y lo que hace
es que te va lento
los comentarios,
¿no?
En este caso
tú tienes estos cuatro componentes.
Imagínate que tienes una API,
tienes cuatro APIs.
Hay tres APIs
que han ido rápido,
¿vale?
Entonces puedes manejar
la ANAP,
puedes ver los posts,
puedes ver el profile,
pero la de comentarios
ha ido súper lenta.
A día de hoy
en React 17
te lo devolvería
todo de golpe.
Entonces,
el tiempo que tardaría
en devolverte
la página de React
sería
el más lento,
el que la API
más lenta,
lo que haya tardado más.
O sea,
que estás jodido.
Esto es como
cuando haces un promisor.
Sería un promisor.
O sea,
en React 17,
vamos a ver así,
en React 17
sería un promisor,
básicamente.
¿Por qué?
Porque tiene que esperar
todos los componentes
a que se rendericen
y el que más tarde,
ya sea porque hace
un fetching de datos
que tarda mucho,
pues lo tendría y ya está.
Con React 18
la idea
ya no sería
hacer un promisor,
sino que simplemente
lo que estarías haciendo
es hacerlas,
ir devolviéndolas
conforme las vas teniendo.
En este caso
creo que no hay un
no hay un promis
que exista,
pero básicamente
sería totalmente asíncrono.
O sea,
sería async total.
En el caso de que
en cuanto tengas una
la devuelve,
lo renderizas
y lo tienes
y ya está.
Lo streameas
y ya está.
Y en el caso de React 17
siempre esperarías
el más lento.
¿Vale?
Esa sería la diferencia.
¿No sería un old settle?
No,
porque un old settle
se termina también
cuando están todos seteados,
ya sea
para bien o para mal.
El tema es que
el promisor,
la diferencia entre
el promisor settle
y el promisor
es que el promisor
espera todas las promesas,
pero si falla una,
peta,
y el promisor settle
espera todas las promesas,
pero si falla una,
espera todas las promesas
igualmente,
¿sabes?
Y luego te dice
cuál ha fallado
y cuál no.
Esa es la única diferencia.
O sea,
que el promisor
al final,
o sea,
lo vais a ver más claro
si hacemos así,
¿no?
Si esto,
por ejemplo,
esto tarda dos segundos,
si esto tarda dos segundos,
si esto tarda cinco segundos,
si esto tarda tres segundos,
pues en total
tarda cinco segundos,
¿no?
O sea,
el promisor tarda
lo que más tarde,
o sea,
la promesa que más tarde.
Ese es el tiempo
que va a tardar el promisor.
En el caso de RIA18,
lo que vamos a ver
es que se van a ir,
que al menos,
y esto es lo que tardaría
el render,
¿no?
Render,
cinco segundos.
Render en ver algo,
me refiero,
de blanco a ver algo.
En RIA18,
en ver algo,
el render en ver algo,
de blanco a ver algo,
serían dos segundos.
Sería el tiempo mínimo.
Y luego,
en tres segundos,
o sea,
en un segundo más,
veríamos un poco más.
En dos segundos más,
veríamos un poco más,
¿no?
Y ya está.
¿Y es mejor streamar el contenido
a que el mismo componente
lo llame?
A ver,
si te refieres a hacer
un useEffect,
evidentemente.
O sea,
siempre va a ser mejor
streamar el contenido,
el servidor siempre va a ser
mucho más rápido.
Esto va a ser,
esto,
a ver,
os cuento una cosa,
¿vale?
Esto que os estoy explicando
es para que entendáis
cómo funciona por detrás.
Esto lo va a hacer
automáticamente
Next.js
y todo este tipo de cosas.
Una cosa
que estoy seguro,
seguro,
que Next.js,
vamos a ver su próxima versión.
Yo no tengo contacto
con la gente de Next.js,
no tengo ni primera idea.
¿Midu,
tienes un video
sobre el tema
de la hidratación?
¿O será posible
que hagas uno?
Tengo,
tengo uno
en mi canal secundario.
Tengo uno por ahí
de clients al rendering
y hablo de hidratación
y todo esto.
Lo que voy a decir
que en Next.js
estoy bastante seguro
que lo que vamos a ver
es que,
como sabéis,
a día de hoy
lo que está haciendo
Next.js
es que tenemos
el fetching de datos
a nivel de página.
Yo estoy bastante,
bastante seguro
que Next.js,
bueno,
estaba por ahí Gonci,
igual no os puede explicar
el spoiler.
Estoy bastante seguro
que una de las cosas
que se ven en Next.js
es el hecho
de poder hacer
un fetching de datos
en lugar de hacerlo
a nivel de página
poder hacerlo
de una forma
más granular
de forma que vamos
a tener ciertos componentes
que podrán hacer
un fetching de datos
de forma totalmente separada.
No sé si utilizarán
alguna técnica,
si harán como un export cons
o si van a tener
como islas,
lo que sea.
Pero esto es una cosa
que seguro que va a pasar
porque desbloqueará esto.
A día de hoy,
claro,
ahora mismo
como es a nivel de página
no tiene mucho sentido
lo que os estoy explicando.
Pero cuando se puede hacer
un fetching de datos
solo a niveles
de ciertos componentes
pues lo vamos a ver
muy claro.
Así que seguro
que es una cosa
que llegará
y es una cosa
que hace mucho tiempo
se le ha pedido.
Pues eso es lo que pasará.
Esto,
como os podéis imaginar,
esto React lo ha hecho
porque le va increíble,
le va increíble
a Facebook.
Esto a Facebook
le va que ni os lo imagináis.
Le encanta.
O sea,
esto es lo mejor
que va a tener
para ellos mismos.
No entendí la parte
que es mejor
streamar el código
comparado a usar UseEffect.
Me pasa un link
que hablo al respecto.
A ver,
esto es muy sencillo.
¡Amigos!
¡Amigos!
¡Atentos!
¡Atentos!
¿Vale?
Un UseEffect
se ejecuta
solo en el cliente.
Entonces,
y es que esto es muy claro.
Esto lo vais a ver,
aquí lo vais a ver muy claro.
¿Qué es lo que pasa
con este código?
¿Qué es lo que pasa
con este código?
¿Qué es lo que pasa
con esta página?
¿Vale?
Mira,
vamos a poner un poco
más de información
para que lo veáis clarísimo.
¿Vale?
Y de verdad
es que esto es vital.
Esto es vital, ¿vale?
Es vital porque,
mira,
¿ves que aquí pone Pikachu?
¿Sí o no?
¿Vale?
Pero yo cuando entro,
¿qué pasa aquí?
¿Qué está pasando aquí?
¿Ves algo ahí raro?
¿Qué pasa?
Que está la página en blanco.
Me refiero,
cuando tú entras a esta página,
que no es la página
más bonita del mundo,
¿vale?
Pero esta es nuestra página.
¿Qué le importa?
Esta es nuestra página, ¿vale?
Pero ¿qué pasa
cuando yo entro a la página?
Fíjate cuando yo actualizo
esta página.
Cuando yo actualizo esta página,
¿ves que hace ahí como un salto?
Da como un saltito, ¿verdad?
Esto es porque estamos
utilizando un UseEffect.
Y esto,
para la experiencia del usuario,
es una basura.
Para que lo veas todavía más claro,
más claro,
para que lo veas todavía más claro,
fíjate en esto.
Imagínate que tenemos una API
que tarda,
yo qué sé,
vamos a poner cinco segundos,
por decir algo,
o dos segundos, ¿vale?
Vamos a poner segundos.
Tú entras a la página
y entonces te sale el resultado,
¿vale?
Esto es el UseEffect.
Y el problema
es que esto,
en la experiencia del usuario,
claro,
en este caso es un Pikachu,
pero imagínate
una lista de noticias, ¿no?
O una lista de artículos,
una lista de lo que sea.
Pues visualmente
es una mierda, ¿no?
Porque el usuario
no está viendo
de primera la información.
Lo que es peor,
además,
no solo es un tema
de experiencia del usuario,
es que si te vas a ver
el código fuente,
¿vale?
Y yo busco Pikachu,
no hay Pikachu, ¿vale?
Aquí en el código fuente
no hay Pikachu
porque esta información
tú la estás recuperando
desde el UseEffect.
Entonces,
como la estás recuperando
desde el cliente,
cuando va a Google
con su crawler
y mira aquí
y dice,
¿dónde está el Pikachu?
Pues no puede,
no lo ve,
no lo ve.
Y por lo tanto,
esto también tiene
un impacto en SEO.
Pero lo más importante
es que tiene un impacto
en la experiencia del usuario,
¿vale?
En el rendimiento.
¿Por qué?
Porque esto,
esto es un salto de la UI
es también cuánto tiempo
está tardando
en dibujarse
en la página.
Esto es rendimiento,
esto es web performance.
Por lo tanto,
siempre va a ser mejor
hacer esto en el servidor.
Ahora bien,
encima de esto,
aparte de que es mejor
hacer un servidor
y que tendríamos aquí
pues toda la información
y tal,
aparte de esto,
es que si tú
en el servidor
tuvieses estos fetch,
imagínate que tienes uno
que tarda dos segundos
y tienes otro
que tarda cinco segundos,
¿vale?
En componentes distintos.
¿Qué pasa?
Que si tú tuvieses
que esperar
todos los fetch
que hace la página,
¿cuánto va a tardar
en dibujarlo
en el servidor?
Pues pasa a tardar
cinco segundos.
¿Cuál es el problema?
Pues que el usuario
se quedará con la página
en blanco cinco segundos.
¿Queremos eso?
No queremos eso.
No queremos eso,
obviamente.
Queremos,
queremos que los usuarios
vean cuánto antes
el contenido.
Para que lo veas,
voy a intentar enseñarte
un ejemplo,
¿vale?
Para que lo veas,
lo veas claro,
¿vale?
Para que veas
lo que es el streaming.
Lo que te voy a enseñar
no es el mejor streaming
porque ahora
el mejor streaming
lo vamos a poder hacer
con React.
Vamos a intentar verlo,
¿vale?
Vamos a intentar verlo.
Vale.
Pero veas que aquí,
vale,
es que va demasiado rápido
pero si lo pongo demasiado lento
va a ser demasiado lento.
¿Qué es lo que está
haciendo esta página?
Lo que está haciendo
esta página
es que tú
cuando entras
te da
una parte
del contenido,
fíjate que
nos va a dar
una parte del contenido,
fíjate que esto
todavía está aquí,
ah, bueno,
espérate,
es que ahora,
espérate porque igual,
igual,
tenemos que limpiar
a ver si ahora,
mira,
fíjate que mientras
se estaba descargando
el HTML
se estaba descargando
aquí cosas,
vale,
hasta aquí,
vamos a dejarlo,
mira,
lo que está pasando aquí
en esta barrita azul
esto es descargar
el HTML,
lo que está haciendo
es un streaming
del HTML
y mientras se está
haciendo un streaming
del HTML
está descargando otros,
fíjate,
esto lo podrás ver
en otros sitios
es que esto no ocurre
en todos los sitios,
vale,
en otros sitios
verás que hasta que no
se descarga el HTML
no empieza a descargar
el JavaScript
pero aquí lo que está
haciendo es
streamear la respuesta
por lo tanto,
cada vez que va
recuperando HTML
pues va diciendo
ostras,
HTML nuevo,
voy a leer HTML,
ostras,
pues tengo que descargar
el JavaScript,
vale,
pues va descargando
de forma totalmente
como en paralelo
el JavaScript,
esto no lo vas a ver
en todas las páginas,
de hecho,
se nota que es streaming
porque si miramos
el content type
me parece,
a ver,
como podemos ver,
de alguna forma
se podría ver
si es streaming
en lugar de,
bueno,
da igual en este caso,
pero solo para que lo sepas
así sería,
se volvería al streaming
y la forma también
es que visualmente
tú vas a poder ir viendo,
vas a poder ir viendo
justamente
cosas
mientras
en el servidor
se siguen haciendo cosas,
o sea,
es como un streaming
de vídeo
donde básicamente
hay un buffer
y se va devolviendo cosas
y es que esto
es súper importante
hoy en día
porque hoy en día
si no,
tendríamos que esperar
todo lo que hace el backend
para poder enseñarle
algo al usuario,
¿vale?
Eso sería el tema.
Van a rodar cabezas
mañana en equipo
en Fotocasa,
nada,
para nada,
¿eh?
No,
no me he enfadado,
¿cómo me he enfadado?
No estoy enfadado.
Madre mía,
se ha regañado.
El día que os regañe
vais a flipar,
vamos,
vais a parecer
un DualShock
de lo que vais a vibrar,
vas a estar temblando.
¡Vamos!
¡Vamos!