This graph shows how many times the word ______ has been mentioned throughout the history of the program.
Midu, ¿es recomendable usar Use Memo o Use Callback siempre?
¡Qué buena pregunta! ¡Qué buena pregunta, Juliox!
No, no, no es buena idea utilizarlo siempre.
No es buena idea utilizarlo siempre.
Use Memo, Use Callback siempre. No, no, no, y no, y no.
Y de hecho es una mala práctica, ¿vale?
Es una mala práctica. A ver, de hecho, hay gente que piensa
que el Use Memo o el Use Callback, para el que no lo sepa,
son dos hooks de React, vamos a buscar la documentación, ¿vale?
Hay mucha gente que cree que al final lo que hacen es optimizar, ¿no?
Porque el Use Callback y el Use Memo lo que hacen,
no sé por qué no funciona ir al hook, pero este, Use Callback.
El Use Callback lo que hace es que te guarda este callback,
digamos que te lo memoriza, memoriza, no memoriza, te lo memoriza,
de hecho, devolve un callback memorizado.
O sea, no vuelve a crear la función.
Y esto está muy bien, o sea, tiene todo sentido el mundo.
Pero el Use Callback, la idea de utilizar el Use Callback,
normalmente no es tanto por un impacto de rendimiento,
sino que es un impacto en el que si tú le estás pasando esta función de aquí,
esta función de aquí, se la estás pasando al hijo, ¿qué pasa?
Que cuando tenemos, a ver, vamos a StackBlitz.
StackBlitz.
Esto es una cosa muy interesante que muy poca gente en React domina o tiene muy clara.
Y la verdad es que entiendo que puede costar,
pero no debería costar tanto.
A ver, a ver cómo lo intento explicar.
Pongamos que yo aquí vamos a crear un estado.
Sé que es muy típico, pero es que esto no es lo importante, ¿vale?
Así que vamos a hacer el típico counter, que no sé qué, que no sé cuánto,
pero es que...
Vale, de esto lo vamos a quitar aquí.
Vamos a poner que esto tiene un counter.
Vamos a poner aquí un counter.
Y el counter recibe tanto el counter como el setCounter.
¿Vale?
Y esto lo que devuelve es un tip que tenga...
Venga, dip, dip.
Hay veces, no sé si os pasa,
hay veces que mi cabeza va más rápida que mis manos.
Me da mucho coraje.
Me da mucho coraje cuando pasa eso.
SetCounter, ¿vale?
O increment.
Vamos a llamarle increment.
Increment.
Me da mucho coraje eso.
¿Vale?
Button.
Porque es como que lo que yo pienso es...
Y entonces mis manos como que me laguean.
Y digo, ¡hostia!
Necesito una conexión neuronal de estas.
Increment.
Vamos a ver si este ejemplo funciona bien, ¿eh?
Si no, buscaremos otro.
¿Qué le vamos a hacer?
Pero...
Vale.
Y aquí tendríamos el increment.
Increment.
Y importamos el useState.
De aquí.
Y está el...
Bla, bla, bla.
Play, grid, min, height.
Place, content, center.
Madre mía.
Hasta los estilos le vamos a hacer a este pedazo de...
A este pedazo de contador.
El mejor contador del mundo.
Venga, ya está.
Arfa, arfa, arfa.
Acosta.
Ya me he envalentonado.
Ya me he envalentonado.
Ya...
Ya lo tengo que hacer bonito.
Bueno.
Más o menos.
Bueno.
Yo voy a dándole aquí.
Esto perfecto.
Hace más uno, más uno, más uno, más uno.
Perfecto, ¿no?
¿Qué pasa con esto?
Si miramos aquí, el tema es que este increment...
Le estamos...
En el componente app.
Tenemos un estado con el counter, setCounter.
Y aquí estamos creando un método que se llama increment.
Y este método que estamos creando aquí lo pasamos como parámetro.
¿Vale?
Como podemos ver, esto funciona súper bien.
Y aquí podríamos volvernos locos y meter un useCallback.
En este caso no tiene sentido el useMemo, pero podríamos meter un useCallback porque esta función se está creando en cada renderizado.
Pero el problema aquí no es tanto el rendimiento.
El problema aquí sería, imaginemos que yo creo aquí un useEffect y le pongo como dependencia el increment.
Por X motivo.
¿Vale?
Olvidemos la razón que hay aquí detrás.
Pero imaginemos que esto se tiene que ejecutar cada vez que le llega una nueva función.
¿Vale?
Que le pasamos una nueva función.
Y es una dependencia de este useEffect que podría ser una dependencia de lo que quieras.
¿Sabes?
¿Qué pasa aquí?
Aquí es donde sí que empiezan a haber los problemas, ¿vale?
Porque si te fijas, cada vez que yo hago un clic aquí, fíjate que en la consola me está diciendo que le está llegando un new increment todo el rato.
Imagínate que esta dependencia del increment, que a ver, ya te digo que no tiene mucho sentido, pero imagínate que yo aquí hiciese una llamada a una web.
¿Qué pasaría con esto, no?
Que yo cada vez que estoy haciendo clic, estaría haciendo el fetch porque me está llegando una nueva función.
Pero mentalmente lo que la gente piensa es que la función que le está llegando es la misma de antes.
Pero no es así.
Porque en React, cuando se renderiza, cada vez que se renderiza el componente, se vuelven a crear todas las constantes que están en el cuerpo de la función.
Excepto aquellas que vienen con un hook.
Por ejemplo, esta línea de aquí, las constantes de counter y setCounter no se vuelven a crear.
No se vuelven a generar.
No va a volver a hacer un useState.
No hace eso.
Pero esta constante de aquí, que al final lo que tiene es una función, esto cada vez que se renderiza por el cambio de estado del counter, está volviendo a crear esta función.
Entonces, ¿hay un problema de rendimiento?
No.
Crear una función así, a no ser que sea un componente enorme, que ya te digo que habría otra forma de mejorarlo, no sería un problema de rendimiento.
Y yo te recomendaría que no utilices useCallback siempre que te encuentres esto.
Utiliza useCallback cuando quieres que la función que le llega, esa función, no cambie.
O sea, no se vuelva a generar cada vez que se renderice el cuerpo de la función.
Porque ahí es donde realmente puedes tener problemas.
Ahí es donde sí que puedes tener problemas.
De hecho, este setCounter lo que podríamos hacer es...
Porque si no, también podríamos tener problemas.
Es que aquí podríamos tener un montón de problemas.
Mira, aquí en el useCallback lo que podemos hacer, pues nada, hacemos aquí el useCallback.
Le podríamos pasar aquí, useCallback.
Lo hacemos así.
Aquí en el useCallback, bueno, tenemos que traer useCallback.
Le podemos decir que no...
O sea, que se renderice con la dependencia sin dependencias, ¿vale?
Y aquí lo que nos podemos encontrar es este problema, ¿no?
Porque claro, ahora el counter, como sea...
Ahora es verdad que solo se lo hemos pasado una vez, pero el contador no cambia.
¿Por qué?
Porque el counter que tiene en el cuerpo de esta función, en este scope, se ha quedado memorizada esta función cuando el counter tenía un valor en concreto.
Por lo tanto, lo que podríamos hacer es que el setCounter, pues sería utilizar el prepCounter y esto que haga esto, ¿vale?
Y de esta forma ahora sí que funcionaría.
Pero fíjate que aunque sí que funcione el contador, ahora el consoleLog que estamos haciendo es uno, porque la función que le estamos pasando siempre es la misma.
Así que utiliza un useCallback cuando te quieras asegurar que la función que estás pasando no cambia, si no es necesario que cambie.
Si tuviese dependencias como por ejemplo esta, aquí podríamos poner el counter, pero no tiene sentido poner el counter cuando ya tenemos un mecanismo para hacer esto.
Aquí estamos creando una función, no lo hagas por mejorar el rendimiento, porque no tiene sentido, hazlo porque necesitas que siempre pase la misma referencia.
No sé si ha quedado claro, yo te he dado aquí mi speech y aquí lo he dejado.
Obvio a jugar, 25. Hola Midu, acabo de llegar. ¿Qué proyectos tienes pensados para crear?