Digamos, estas son las mejoras, así que, ¿cuál es la más importante, de la que más se habla que todo esto?
Bueno, la más importante es el modo concurrent, ¿vale? De concurrencia.
Este modo, ya lo dice aquí, el renderizado concurrente, que básicamente lo que hace es desbloquear un montón de nuevas posibilidades para React.
¿Y qué quiere decir el modo concurrente? Porque dice concurrente, ¿qué quiere decir?
Que es corriente dos veces, no. Concurrencia lo que quiere decir es que puede hacer más de una cosa a la vez.
¿Y a qué se refiere exactamente en React con el modo de concurrencia? Porque aquí tampoco queda mucha información.
Lo que quiere decir es que el modo de concurrencia, lo que React hasta ahora como funcionaba es que hacía una actualización de la UI y no podía pararla.
Tenía que esperar para hacer la siguiente. Entonces, digamos que hacía una actualización de la UI, una detrás de la otra, y no la podía parar.
Esto hay una, las típicas demos estas muy típicas, de que tú cuando estás en un input, ¿no?
Tú te pones a escribir en un input y te empieza a laguear el input, ¿no?
¿Por qué? Porque a lo mejor el cambio de estado es muy costoso y la UI no le da tiempo de ir actualizándose.
Pues el concurrent mode lo que va a hacer es que va a poder hacer más de un cambio de la UI en paralelo a la vez.
Y además lo que puede hacer es cancelar un renderizado. Imagínate que tú tienes un cambio en la UI y React dice,
¡Ostras! Como tengo cuatro renderizados que voy a hacer y estos tres no son tan importantes, pues voy a hacer directamente el cuarto.
Se los puede saltar o puede saltarse algunos, o sea que es bastante interesante.
Este es el modo concurrent, ¿vale? Concurrent mode. Este es lo que comentan aquí.
Ahora, como te puedes imaginar esto, que es un cambio muy bestia, muy bestia, ¿vale?
Lo que nos permite es desbloquear un montón de nuevas funcionalidades que vamos a ir viendo.
Mira, aquí lo explican. Preparar múltiples versiones de la UI al mismo tiempo.
Eso sí, ten en cuenta que esto que estoy hablando, porque hay mucha gente que a lo mejor se pone,
¡Wow! ¡Qué difícil y tal! Esto va a ser casi gratis. O sea, no te vas a tener que preocupar.
Es más al revés. Va a ser declarativo de que tú te vas a tener que preocupar más bien
de qué cambios son importantes o no. Y se lo vas a decir directamente a React.
Le vas a decir, mira, este cambio es importante y este no. Y ahora veremos cómo se lo vamos a decir, ¿vale?
Venga, otro cambio que esto es un win totalmente gratis y que además, pues no vamos a tener que hacer absolutamente nada
y va a ser un win de rendimiento brutal.
React 18 añade un nuevo automatic batching. ¿Esto qué quiere decir?
Esto lo que quiere decir es que hasta el día de hoy, en ciertos casos, cuando tú hacias dos set states seguidos,
¿Ves? Así, de esta forma, dentro de un set timeout, dentro de un promise, dentro de este tipo de cosas,
pues lo que pasaba es que, ¿ves? Ponía React lo renderiza dos veces, uno por cada estado.
Esto lo llegamos a ver aquí en directo, utilizando una de las alfas y tal, para ver esta mejora.
Básicamente, cuando tú en un set timeout, creo que en handle clicks, por ejemplo, dentro de promesas,
tú hacías dos set states, React lo renderizaba dos veces, una por cada actualización del estado.
O sea, por cada set count, set flag, un renderizado. Y esto es una mierda, pinchada en un palo.
¿Por qué? Porque lo que estás haciendo es re-renderizar la UI sin necesidad.
Y esto, pues, tiene un coste, depende de cómo grande sea el componente, es bastante tocho, tiene este tipo de cosas.
Ahora, esto, en este caso, la nueva versión, ¿qué es lo que ocurre en la nueva versión?
Bueno, es que si te fijas, este código de aquí y este código de aquí es el mismo, es exactamente el mismo.
Pero esto es React 17, esto es React 18. En React 18 lo que va a pasar es que solo lo va a renderizar una vez al final.
¿Qué quiere decir esto? Pues que automáticamente React va a detectar, va a hacer un batch.
O sea, va a hacer como, ¿cómo se dice? Un batch. Un batch es como que lo va a empaquetar, ¿vale?
En una sola entrega. Lo que va a hacer es decir, ostras, tienes dos set states, pues hasta que no termine de actualizar
internamente el estado de los dos, no lo voy a renderizar. En lote, muy bien, un lote. Ahí está, me ha gustado.
En lote, mira qué fácil, ¿eh? Pues en lote, efectivamente, en lote. De una vez. Lo que dice es, bueno, voy a abrir a todos los set states y ya está.
Esto es súper típico después de hacer un fetch, por ejemplo, el set error a null. El set response, le pone la respuesta.
Set loading a false. Pues eso era súper, súper bestia. Súper bestia. A ver, os lo voy a enseñar un momento en código.
A ver, bitenew react. A ver aquí si lo podemos hacer. Y aquí veremos si podemos probar también.
Pero, bueno, básicamente el código que yo te comento es el típico código.
No sé si esto estará haciendo que pete mucho porque esto es bastante costoso en el navegador.
Bueno, pero esto lo quitamos. Vale. Lo que digo es lo típico, el típico useEffect. Este, useEffect, ¿vale?
Que hace esto de fetch, tralala, ¿no? Y tú tienes aquí un then y aquí tienes un catch, ¿vale?
Y qué es lo que se suele hacer aquí, ¿no? Pues tienes, por ejemplo, loading, setLoading, useStateFalse.
Este código está en montones, montones de sitios, montones.
Y aunque tú no lo veas, porque, por ejemplo, alguien me diría, bueno, pues es que yo utilizo React Query.
Bueno, pues es que React Query a lo mejor esto lo tiene por debajo.
O sea, que estas ventajas, estas mejoras, igual también las vas a tener de gratis, utilizando un montón de cosas.
Es algo totalmente... No es nuevo porque antes estaba ya en alfa y se podía activar.
Era opcional activarlo, pero no se podía activar. Lo tenías que poner tú, ¿vale?
Entonces esto es lo típico, ¿no? Decías, vale, pues aquí es el loading, es true.
Y el setError lo pongo a null, ¿vale? Antes de hacer el useEffect, que esto, pues tiene aquí, yo que sé, lo que sea, ¿vale?
El input del usuario, por decir algo. Vamos a poner el input del usuario.
Input, setInput, useState.
Cada vez que cambia el input, pues hago esta llamada.
¿Qué pasaba aquí? Pues setResponse con el response.
SetLoading con el false.
Bueno, que lo podías hacer también en un finally, ¿eh?
Pero bueno, lo dejo así para que lo veáis claro.
SetError a null, por decir algo, ¿no?
Y esto, pues aquí lo mismo.
SetResponse a null.
Esto false.
Y esto aquí el error.
Bueno, este código está en un montón de sitios, ¿no?
Entonces, lo que teníamos aquí, lo que muchas veces pasaba,
es que aquí, aunque tú no te dabas cuenta, se estaba renderizando más de una vez.
En este caso no, pero sí dentro de estos fetch.
Lo mismo con handleClicks, con handleSubmits.
Esto se ve un montón.
Bueno, pues ahora no va a ocurrir.
Ahora lo que va a hacer es detectar todo esto y va a hacer un solo render, ¿vale?
Con la nueva versión de React.
No sé si aquí ya estará...
No, está con la 18.
Vamos a ver si este código funciona.
A ver, a PokeApi.
PokeApi.
Vamos a pillar la PokeApi un momento.
PokePokémon, hazte con todo, sí.
Es mi destino, mi ilusión, Pokémon.
Vamos a pillar este.
Vamos a pillar este.
Lo vamos a poner por aquí.
Y vamos a poner aquí, por ejemplo, a response.
Por decir algo.
Solo para que salga algo.
Esto debería funcionar, ¿no?
O yo me estaba imaginando aquí algo...
¿Sabes?
He dicho, bueno, esto debería funcionar porque me da la gana.
Ah.
No lo sé.
Pues no lo sé.
A ver.
Hola.
Hola.
Hola.
Bueno, también es verdad que he puesto React 18 y a lo mejor...
Ah, no, no he puesto nada aquí.
O sea que esto debería funcionar.
Si esto no estoy haciendo nada.
Bueno, no sé por qué no funciona.
Deberíamos mirar la consola a ver.
Bueno.
Si no, luego lo probamos en terminal y lo veremos mejor.
Luego me copio el código.
Bueno, lo importante es eso.
Que tienes que saber que esto se renderiza una vez.
Lo vamos revisando.
Luego miraremos de ir probando.
Vamos a más cosas.
React 18 añade el input, el use effect.
Ah, es que no...
Es que esto es lo malo de no tener linter.
Esto es lo malo de no tener linter.
Que uno se cree...
Vale, ya lo tenemos aquí.
Gracias, gracias.
Vosotros, ustedes son mi linter.
Mi linter favorito.
Mi linter favorito.
Igualmente no veo que me salga aquí el response.
Response, set response.
Response.
Ah, aquí falta el response.
Vale.
Set response.
Bueno, tampoco pasa.
Veo que funcione del todo esto.
Loading, set error, bla, bla.
Este response...
Bueno, quería ver por qué no funciona.
.habilities.moves.
Vamos a ver si tiene uno que sea...
¡Hostia!
Que me peta esto.
Moves.name.
Vamos a ver el .name.
Response.
Ah, perdón.
Me falta el tojson.
¿Ves?
Es que he ido muy a saco antes.
En automático.
Res.json.
Vale, ya está.
Ya está.
Ahora sí, ¿no?
Tampoco.
Response.name.
Pues nada.
Response.name.
Ahora sí.
Vale, ya lo tenemos ahí, ¿vale?
Entonces, ahora esto lo que se supone es que si pusiéramos aquí un console.log,
que va a ser complicado porque veo que aquí no tengo toda la consola,
pero si yo pongo aquí un console.log, aquí, por ejemplo, render.
Vamos a poner esto, render.
Voy a guardar los cambios.
Nos vamos a ir aquí.
Vale.
Inspeccionar.
Vamos a ver aquí la consola.
Mira, fíjate la de renders que ha hecho.
¡Cinco!
¡Cinco renders!
Ha hecho un montón de renders, ¿vale?
Sí, es un objeto, pero ya ha puesto el .name.
Entonces, ha hecho cinco renders solo con este código.
¿Qué es lo que habrá pasado?
Aquí hay uno y, claro, debería ser aquí otro y aquí otro.
O sea, debería ser tres.
Pero, en cambio, está haciendo cinco.
O sea, está haciendo cinco renders.
Se está ejecutando cinco veces este componente.
Y esto es justo por lo que comento, porque no está haciendo el batching.
Si probamos, voy a probar a ver si esto se lo come con patatas, ¿vale?
A ver si esto es automático.
Si yo pongo aquí el Riat 18, guardo los cambios.
Refresco.
Voy a ver.
Sí, sí, parece que sí que se lo come.
Hostia.
A ver aquí.
Hostia, ahí se ha vuelto loco.
Pero aquí parece que sí que se lo ha comido.
Vamos a ver.
¿Vale?
Vamos a ver.
Aquí me ha hecho lo mismo.
Es que, ¿veis que hace una cosa rara?
No sé si es que tiene algún...
Se cachea o algo.
Pero no...
Lo vamos a probar luego en locales, que sea más fácil, ¿eh?
Sea más fácil.
Si te hace toda la lógica fuera de la función useEffect, pasa lo mismo.
A ver, el problema no es la lógica.
El problema son los setStates.
Los setStates.
El problema es el input.
Pero el input solo cambia una vez, ¿no?
Reinicia el web server desde bit.
Visto.
Ah, mira, con npm install y todo.
A ver ahora.
Que tengo que actualizar la...
A ver ahora.
Vale.
Pero es cuando levanto...
Cuando abro las herramientas de desarrollo.
Bueno, ahora me he hecho 10 renders.
No, pero ¿veis que se me queda como tonto?
Eso es por algún tema de la caché.
Es algo raro que está aquí como en un bucle eterno, ¿eh?
Pero bueno.
Funciona, funciona.
El código va con lag.
Lo que nos queda es el tema este de ver lo que...
No le pases el input.
No, bueno.
Claro, pero si no le paso el input es un poco rollo.
También estaría bien poder ver la consola aquí, ¿no?
No, porque funciona aquí.
A ver si vemos aquí la consola.
Ta, ta, ta.
¿Ves?
Ahora se está poniendo 10 renders.
O sea, esto está peor.
Amigos, esto está peor.
Esto está peor.
¿Qué está pasando aquí?
Ahora salen 10 renders.
Antes salían 5, ahora salen 10.
No puede ser.
No puede ser.
A ver qué está...
No, es que está...
Tarda un montón.
Lo vamos a probar el local, ¿vale?
Porque es que si no, nos vamos a adaptar ahí un buen rato.
Venga, vamos a ver más cosas y luego seguimos con eso, ¿vale?
Bueno, el response, el optional chaining sí que es bastante.
React 18 nos sirve.
Ya está, sí, sí.
No, hombre, vamos a esperar.
Se cancela.
Nos quedamos en React 17.
No, ahora lo instalamos en condiciones.
A ver si con bit funciona.
Lo probamos y tal.
Venga, React 18 también añade las transiciones.
De hecho, voy a ir añadiendo esto...
Voy a hacerlo por aquí.
NPE minute bit.
Creo que es así.
Ah, no sé si hay que hacerlo.
Voy a hacerlo aquí por si acaso.
Vale.
React 18 test.
CD.
React 18 test.
Vamos a hacer el NPE minute bit.
Creo que esto nos pregunta.
React 18.
Vamos a decir React.
React.
Vale.
React 18.
NPE install.
Esto me debería estar la de...
Bueno, ya que estoy, voy a aprovechar...
Voy a intentar utilizarlo bit con React 18, ¿vale?
Entrar aquí 18.
Y vamos a ver si es totalmente compatible con bit.
¿Vale?
18.
Hacemos un NPE install aquí.
Y ahora probamos el código también que habíamos puesto por ahí.
A ver, a ver.
Vamos a decir NPE run dev.
¿Vale?
Pa, pa, pa.
¿Vale?
Parece que funciona.
Funciona.
Vamos a traernos esto por aquí.
Y ahora sí probar lo que tenía antes, ¿vale?
Ahora así no tenemos que utilizar estas cosas de aquí.
Nos vamos aquí a la app.
Me pego todo esto.
Me vuelvo aquí.
Ya tengo aquí el nextoma este.
Voy a quitar el web container este.
Nos vamos a inspeccionar.
Nos vamos a la consola.
Y aquí salen 10 renders.
O sea, es peor, ¿no?
1, 2, 3, 4, 5, 6, 7, 8, 9, 10.
O sea, salen 10 renders.
Que debería salir menos.
Lo cual es bastante curioso, ¿no?
Y esto ahora, a lo mejor es un error que tienen.
Pero a mí esto me sorprende bastante.
¿No será que el automatic batching...
Ojo.
Ojo.
Ojo.
Porque este que dice React18 adds automatic batching y tal.
¿No será que el automatic batching este solo funciona?
Lo vamos a ver.
Automatic batching solo funciona cuando dice...
Es un...
¿Vale?
Agrupa los multipliers set states.
Claro.
Igual necesitamos utilizar el nuevo query root, ¿eh?
Ahora aquí en el punto de entrada de nuestra aplicación.
En el main.jsx.
Vale.
Ahora entiendo por qué pasa esto.
Ahora os explico por qué.
Necesitas el query root.
Ya, pero como ahí ponía...
Tienes que instalar no de IPC.
Será cabrón.
Será rata.
Vale.
El hecho de que sean 10 es por el stick mode, ¿vale?
Eso es la razón por la que hay 10.
Porque por la que se doblan los renders.
Ahora, pensaba que el automatic batching lo iba a hacer directamente sin necesidad de utilizar el query root.
Pero como vamos a ver ahora, también hay nuevos métodos en React DOM, ¿vale?
Ahora hay nuevos métodos en el React DOM client.
Aquí en el React DOM, que pone que también ahora tiene un client, vamos a utilizarlo, hay uno que se llama create root, ¿vale?
Y en el query root este le tenemos que decir, por un lado, create root.
Le tenemos que decir el contenedor donde vamos a renderizar.
Dice replace real contender, no sé qué, no sé cuánto.
A ver, la documentación.
Create root.
Vale, tendríamos que decirle donde el nodo que queremos, bueno, el elemento que queremos renderizar.
En este caso vamos a poner todo esto, porque me imagino que esto funciona bien.
Y luego le añadimos un punto render y vamos a decirle que nos lo renderiza aquí.
Pensaba que el automatic batching lo iba a hacer automáticamente, sin necesidad de hacer esto.
Pero bueno, este sería, si queréis empezar a, como habéis visto, es totalmente gratis actualizarlo.
Y todo debería funcionar exactamente igual, ¿no?
En este caso, igual es al revés.
Sí, sí, es al revés, que la he liado yo.
La he liado yo.
Esto es yo que estoy acostumbrado.
Aquí es el contenedor y luego lo que renderiza.
De hecho, lo pone aquí, que soy yo, que lo he visto aquí y ya me he liado.
Bueno, podéis actualizar React 18, no estaríais aprovechando sus ventajas, sus beneficios y tal,
pero podríais actualizarlo y ya está.
Tened en cuenta una cosa que esto es bastante importante, que React 18, no sé si lo pone en el blog,
pero han quitado, a ver si lo pone, se supone que iban a quitar el soporte a Internet Explorer 18.
Ah, 18, sí.
Internet Explorer 11.
O sea que si necesitáis compatibilidad con Internet Explorer 11, que tengáis en cuenta que React 18 no funciona.
O sea que tenedlo en cuenta, ¿vale?
Bueno, si queréis, vamos a poner esto, React 18, y vamos a dejar como estaba.
Voy a copiar esto.
Voy a tirar un momento para atrás para que veáis un poco la diferencia.
Y esto sería React 17 y 18, pero sin las cosas nuevas, buenas, ¿vale?
Para que veáis la diferencia.
Entonces, si queréis migrar y empezar a utilizar las cositas de React 18, tenéis que utilizar el query root,
le decís dónde lo queréis renderizar, punto, render, y lo que queréis renderizar.
Vamos a guardar los cambios a ver si funciona.
¿Vale?
Parece que todo funciona, pero aquí parece que todavía siguen poniendo un montón de renders.
Un, dos, tres, cuatro, cinco, seis, siete, ocho.
Vale, está haciendo uno menos que antes.
Ya os digo que el que sean ocho, esto es por culpa de esto.
Bueno, porque si esto lo quitamos, vamos a ver que seguro hace la mitad de renders.
De hecho, solo hace tres.
Solo hace tres renders.
O sea, antes, en React 17 estaba haciendo cinco renders, y aquí está haciendo tres renders.
El tema es que si utilizáis el String Mode por temas de chequeos que hace en modo de desarrollo,
vais a ver que hace un montón de renderizados, ¿vale?
Solo para que lo tengáis en cuenta.
Pero solo con el cambio que hemos hecho, ya podemos ver que están bajando el número de renderizados.
Y no hemos hecho ningún cambio en el código.
O sea, no hemos hecho absolutamente nada.
Porque, claro, tiene sentido que sean tres renderizados.
Este sería el primero.
Nada más entrar al componente a renderizando, ¿no?
Este sería el Fill Render.
Luego, esta actualización de estado.
Esta sería el segundo render.
Segundo render.
¿Vale?
Con estas actualizaciones de estado.
Y si entra en esta, este sería el tercer render.
Tercer render.
¿Vale?
Esto serían los tres render.
O sea, tiene sentido lo que hace.
¿Es como String en JavaScript?
Bueno, el String Mode lo que hace básicamente es que te avisa si estás utilizando APIs deprecadas,
si hay algo que no estás utilizando bien, si estás utilizando algo que puedas migrar a una nueva funcionalidad, por ejemplo.
Eso es lo que hace.
Lo tenéis documentado.
Pero yo, ya os digo, esto solo funciona en modo desarrollo.
En modo producción no hace absolutamente nada.
Punto pelota.
Luego, decía alguien si se podía analizar lo que estábamos haciendo en las...
Ah, no tengo...
A ver.
React Developer Tools.
React Developer Tools.
¿Las tengo que tener instaladas?
Vale.
Lo que las tengo desactivadas.
Igual porque chupan un montón.
Té, té, té.
Vale.
Venga, os leo un rato.
Un momentito.
¿Vale?
Mientras voy activando la extensión de React.
Y os digo.
Validación de desarrollo.
Sí, es solo de desarrollo.
Es como para...
El modo estricto ya te digo que te salta warnings y cosas así en el caso de que estés utilizando cosas deprecadas y ya está.
Eso es básicamente lo que hace.
¿Crew React App ya usa React 18?
No creo.
No creo, pero no creo que sea muy difícil.
O sea, podéis instalar Crew React App, os haría todo el scaffolding y luego en el package.json le cambiáis la versión a React 18 y ya lo tendrías.
En este caso ya lo tendrías, ¿eh?
Mido, tu validación de error está mal.
Siempre se te anula.
Lo he hecho a posta.
Lo he hecho a posta porque como podréis ver...
O sea, lo he hecho rápido antes, ¿eh?
Pero es porque no he pillado el error este, ¿no?
Básicamente.
Ya está.
Ya lo tenemos aquí.
Set error.
Y aquí en el catch tendríamos el error.
Pero no lo he hecho a posta porque no iba a entrar por ahí y ya está.
Y vamos a ver si ahora sí que me pilla esto.
A ver.
¿Dónde está React?
React.
A ver.
¿Dónde están mis herramientas de React?
Ahora.
Aquí lo tendríamos.
Bueno, lo podríamos ver fácil en el profiler, ¿no?
Que antes alguien me decía, ¿se puede ver fácil?
Bueno, lo hacemos aquí.
Lo paramos.
Y aquí podemos ver los tres renders que ha hecho, ¿no?
Los tres renders y podemos ir pasando.
¿Quién ha causado la actualización?
Pues App, ¿no?
Y aquí tendríamos los tres renders.
Sin necesidad de poner el console.log, lo podéis hacer así.
Además, si os fijáis, tenéis ahí prioridad.
¿Veis que pone normal?
Eso me imagino que es por el tema de las transiciones que vamos a ver ahora también, que es bastante importante.
¿Así de fácil emigrar React 18?
¿Solo cambiar el package y añadir script?
Sí.
Sí.
Pero tened en cuenta que el cambio de concurrencia.
Esto es una cosa importante, ¿vale?
Si no habéis hecho cosas muy raras en vuestros proyectos, seguramente sea así de fácil.
Pero el hecho de que las actualizaciones de la UI ahora sean concurrentes y todo esto, puede ser, sobre todo con los use layout effects y cosas así, puede ser que alguna cosa cambie.
No creo que sea muy grave, pero tened en cuenta que ese cambio puede afectaros de alguna manera, ¿vale?
Vale, ahora me decís, prueba React DOM sin strict mode.
Vale, lo prueba.
Vamos a probarlo.
Tenemos aquí el create root este normal.
I'm root.
Y vamos a probar este para ver como si hay alguna diferencia, ¿vale?
Sin el modo estricto.
Porque a lo mejor vemos que incluso funcionaba mejor antes.
¿Vale?
Refrescamos.
Vamos a darle...
O sea, espérate, que me lo he cargado.
Me lo he cargado, me lo he cargado.
¿Qué ha pasado aquí?
Claro, no sale nada.
¿Por qué no sale?
Ah, React DOM no está defined porque no lo estoy importando.
Ay, qué difícil cuando no paras de vivir con linter y de repente te quitan linter.
Es como si ahora me quitaran el Gihaco Pilot, ¿sabes?
O sea, serías de...
Cosas raras como cuáles.
Pues que si tú estás...
Mira, si utilizas el use layout porque...
Imagínate que lo utilizas para hacer tracking después del use layout effect.
No sé por qué harías eso, pero puede pasar, ¿vale?
Entonces, si por lo que sea tú haces un use layout y te fías de que cada vez que se renderiza haces un tracking de lo que sea,
esto a lo mejor ahora de repente te encuentras que hay menos trackings.
Hay menos tracks.
Porque ahora puede ser que ocurran menos, ¿sabes?
Ahora ya no es tan seguro.
Ahora puede cancelar el renderizado React.
Eso sería una cosa rara, por ejemplo.
Pero ya te digo que sería un poco extraño que utilicéis use layout effect.
Render is not a function.
¿Vale?
Esto es porque a lo mejor hay que importarlo como antes.
Vamos a poner react-dome, from react-dome.
Y vamos a utilizar el antiguo.
Mira, react-dome is no longer supported in react-18.
Use group route instead until you switch to new map.
Claro.
¿Vale?
¿Vale?
¿Vale?
Bueno, pues podemos ver que aquí tenemos 3, 4, 5 renders, ¿eh?
Y he quitado el switch mode.
O sea, tenemos 5 renders.
Y aquí lo podemos ver claramente, ¿no?
En el profiler, si yo aquí hago un reload y ahora paramos aquí.
Bueno, aquí me pone 4.
Me pone 4.
Pero ya es uno más, ¿eh?
Ya es uno más que el de antes.
O sea que...
Además, fijaos...
Mira, fijaos en este cambio.
Este cambio es un importante.
Que es el tema de inmediato.
Sí, puede ser que bit...
Bit es el reemplazo de webpack.
Puede ser.
A ver, no es un reemplazo one to one, pero lo podría ser, ¿eh?
Vale.
Pues fijaos aquí que pone prioridad inmediata.
Eso es importante y luego lo veréis por qué.
Porque veis que aquí todas las prioridades son inmediatas.
Todas prioridad inmediata.
Bueno, ya podéis ver que se está renderizando más veces que si quitamos esto y utilizamos este.
Ahora ya sí que lo hemos demostrado empíricamente.
Bueno, tengo que darle aquí.
Ahora me va a dejar fatal.
Y vamos a ir siempre 4 ahí también, ¿sabes?
Me va a dejar fatal.
Me va a dejar fatal.
Vamos a ver.
Ahora me va a dejar fatal y también me va a poner 4 ahí.
Ah, es que le he dejado el stream mode, joder.
Le he dejado el stream mode.
Que uno es con stream mode y otro sin stream mode.
Vale, ahora sí.
Uno de tres, ¿vale?
Bueno, ya vemos que ahora sí tenemos el tema este de que se están haciendo menos los renders.
Y fijaos que en el otro ponía prioridad inmediata y aquí pone prioridad normal.
Eso es porque en la versión anterior de React siempre teníamos la misma prioridad, básicamente, que es inmediata.
Pero ahora vamos a tener dos prioridades y lo vamos a seguir viendo en el hilo, ¿vale?
En el hilo ahora podemos ver que en React 18 también se añade una cosa que se llaman transiciones.
¿Qué son las transiciones?
Hola, Cristian, desde Colombia.
Excelente contenido.
Muchas gracias.
Majo.
Más majo.