Context API - explicado al detalle - con ejemplo práctico y solución al problema de renders - React 

Miedo :C

Gracias a ti por dejar tu comentario!

Gracias amigo y si disfruto bastante haciendo estos videos :)

Super!! Ya tengo listo uno sobre el useReducer, tengo que terminar de editarlo para que no quede tan largo y ya mañana lo subo :)

Gracias a ti por comentar :)

Luis, consulta. Trabajando con los estados, noto que siempre me carga uno atrasado digamos.. tengo que hacer dos clicks para que me cargue el estado nuevo en ocaciones.

Gracias Eric :)

Me gusta redux pero hay muchas formas de manejar estado global, no hay mejor ni peor, aprende lo que puedas y tu mismo sabras decidir

He estado ocupandome de algunas cosas pero en breve retomo 🙂

Hola Manuel estas en lo correcto cuando se actualiza un estado del contexto afecta globalmente a todos los componentes que lo consuman

Hola Fernando si claro sin problema, el formato que necesites, por lo general sólo obtienes la url y la utilizas ya sea en una imagen o como background

@@LuisCabrera Vas a subir más de react??

@@franmartin2758 Si está semana subo dos videos jeje

Hola Martin tienes razón es un concepto bastante extraño, yo mismo no lo comprendo del todo bien, por ello no lo pude explicar mejor, luego voy a rehacer este video, pense en borrar este pero creo que mejor lo dejo mientras no saque el otro Aunque esa magia sólo ocurre en un escenario muy particular Actualmente si hago en un provider un cálculo como un filtro lo memorizo const filteredProducts = useMemo(() => ...., []) También si dentro de un provider creo una función, la memorizo de igual forma const getProducts = useCallback(() =>... , []) Para poder evitar re-renders, y evitar bucles infinitos cuando ocupo algo de esto en algún efecto de un componente Espero pronto entender mejor ese concepto o sí llegas a tener la respuesta me la comentas por aquí :)

@@LuisCabrera Hola Luis!! finalmente creo haber entendido como funciona todo esto y queria copartirtelo. Es más simple de lo que pensaba. MovieList se vuelve a renderizar por el simple hecho de ser un componente hijo de la App y lo que sucede es que App esta cambiando su estado (ya que al hacer el UserContext.Provider dentro de App, el estado esta dentro de App; ahi es donde utilizamos useState), por eso, aunque ni las props ni el estado de MovieList cambien, se vuelven a pintar de todas formas(porque su padre App lo hace... es en App donde tenemos user, setUser = useState y ese estado esta cambiando, volviendo a renderizarse App y todos sus hijos). * Esto se puede evitar haciendo React.memo envolviendo la MovieList, ya que sus props/estado no cambian y no vuelve a renderizarse, aunque su padre cambie(React.memo lo evita comparando las props de MovieList), OJO.... todo siempre y cuando desde MovieList NO se este usando: useContext, lo que invalidaria el memo// De esta manera evitamos el "re-render heredado" por ponerle un nombre. Cuando creas un componente UserProvider y envolves a los demas componentes hijos de App, al llevarte todo a otra parte estas generando "la magia". En realidad es simple... Primero: no estas envolviendo a la App, sino a sus hijos, por lo tanto App nunca se entera de cambios en el estado (que ahora esta en otro lado, en ese UserProvider) ni vuelve a renderizarse y sus hijos no deberian renderizarse ya que la App tampoco lo hace. Segundo: Mientras que el navbar que SI esta consumiendo el contexto se volvera a renderizar. Incluso si le haces React.memo (ya que este no funciona al usar el contexto). El funcionamiento del contexto es que si el "value" cambia, todos sus consumidores se vuelven a renderizar (por mas useMemo/useCallback/React.memo que utilicemos) Lo que sucede es que todo componente que consuma el contexto se ve encadenado a los renderizados del provider, si este cambia su estado (por ende el value que enviamos) todos los consumidores vuelven a renderizarse. MovieList no lo consume, por ende la unica forma en la que se volveria a renderizar seria que cambien sus props/estado, algo que no sucedia, pero lo que si sucedia y provocaba sus renders eran los cambios en App. Es curioso porque al estar haciendo el provider y toda la bola, uno no se da cuenta que esta metiendo el estado en la App. Y pasa desapercibido y es dificil entender que sucede realmente, de ahi creiamos que "era magia" Saludos!

@@martinfernandez9644 Super completo 🙂 esta genial, creo que volvere a construir un ejemplo para entender mejor lo que comentas, tiene bastante sentido

@@LuisCabrera con el compiler podrás entenderlo más rápido. Saludos!

Hola! En VS Code para windows se mantiene presionada la tecla ALT mientras que haces click en los lugares donde deseas colocar cada uno de los cursores

@@LuisCabrera Me encanta la velocidad de Respuesta, he aprendido muchisimo y eres muy dedicado en los videos y en la comunidad, por lo mientras seguiré viendo mas cursos que ya he recomendado a otros, Ojala abras algún canal de comunicación para tu canal próximamente como Discord. +1 !!

@@AlanDanielx ​ Gracias amigo Alan :) pronto, cuando tenga un poco más de contenido abriré un Discord

Hola! Si se puede evitar, memorizando con useMemo los datos y con useCallback las funciones en la definición del Contexto. Como nota importante, cuando usas una librería de manejo de estado como redux o similar, estas tareas de evitar los renders las suelen hacer internamente los paquetes

@@LuisCabrera muchas gracias por tu tiempo, todos tus videos me han ayudado bastante , muchas gracias

​@@ulisescruzgonzalez2677 Gracias amigo Ulises, también en un futuro espero actualizar estos videos :) siempre habrán varias cositas para corregir y mejorar

misma cosa yo jajaja, tampoco entiendo, se le paso explicar ese detalle pero no menos importante

Hola, efectivamente el que un componente consuma un contexto lo limita a no ser reutilizable fuera de dicho contexto. Pero no pasa nada, teniendo en cuenta esto utilizarlo cuando lo veas necesario. Generalmente tendrás componentes reutilizables que sólo consumen props para las tareas específicas (Como un botón).

Las traducciones podrían ser tranquilamente parte de otro contexto. De hecho tiene mucho sentido, ya que será utilizado por todos los componentes. Saludos

Usa la que mas te guste, prueba las dos :)

@@LuisCabrera Una pregunta Maestro estaría mal si siempre uso Context para cualquier aplicación pues lo pregunto por que siempre escucho a cada rato Redux, Redux, y con context podemos hacer lo mismo de una manera mas sencilla y fácil de comprender que Redux

Si te funciona y te sientes cómodo estará bien! sin problema! Mas allá de las tecnologías que uses (Context o Redux) lo mas importante será que seas bien ordenado para que entiendas todo lo que hiciste a medida que pasen los meses/años :)

No debería, sólo es especificar donde sea necesario que puede tomar el valor de null o el requerido

Me dolieron los oídos 😂😂