Seba Cardoso
Henry J. Perez
Wladimir Rocha
Miguel Angel Reyes Moreno
Gilbert Ardila
Jhon Eduard Bocanegra Ortiz
Darío Condori Humerez
Cesar Augusto Guzman Garrido
Nicolas Cena
Mariangelica Useche
Team PlatziJuan Camilo Lentino Villalba
Xavier Flores
Juan Pablo Jimenez
Gualberto Montiel
Vinci Guerra
Fernando Alejandro Yerena Ramos
Henry J. Perez
Francisco Salazar
Cayo Legal
Gonzalo Blasco
Juan Diego Mejia Maestre
Harold Zurita Simon
Alexander Arismendy
Mariangelica Useche
Team PlatziWilliams Munguía
Andres Prieto
En mi experiencia personal una vez empece un proyecto de React con la idea de no usar Redux porque queria hacer el bundle mas chico. Asi que use el Context de React y me sucedio que mientras la apicacion crecia era muy complejo de debuggear. Al final termine usando Redux, solo porque es mas simple de integrar.
Te entiendo, me paso exactamente lo mismo.
Y si, Redux tiene un ecosistema muy completo y herramientas que facilitan muchas cosas.
Pero supongo que para aplicaciones "pequeñas" quizas Redux seria un overkill, ademas que el Context API esta ahi mismo y si sabes que la app no va a crecer pues te facilita las cosas
Yo tengo un proyecto relativamente complejo y usé una alternativa llamada zustand, es super chiquito
Diferencias entre Redux y Context
Cuando un sistema es opaco y no determinista, es dífícil reproducir errores o agregar nuevas caracterí sticas
Context API
Redux vs Context API
al principio usaba props y se creaba el props hell, luego conocí useContext y wow que belleza, ahora con redux espero tener una buena experiencia
Redux para proyectos grandes
useContext soluciona de forma fácil esos problemas. espero que terminando el curso entienda la necesidad de usar Redux aun cuando aumenta el peso del bundle
Saludos a todos,
Aquí pueden ver mis apuntes de esta sección:
https://firstguzman.notion.site/Antes-de-empezar-a990a7cb5a954dff86739e597b81e424
Quedo atento a cualquier sugerencia, duda o comentario. Nos seguimos viendo durante el curso 😊😊
Quisiera hacer un aporte-pregunta ¿No podriamos evitar el re-renderizado en useContext aplicando de forma correcta un memo en los componentes que no cambian?
Sí, como comenté estas comparaciones fueron "out of the box". Usar memo es una optimización que podemos hacer. Buen aporte. Gracias.
Redux vs. Context API
Depuracion
Redux tiene un depurador que nos permite llevar trazabilidad de como se ha ido comportando nuestro estado
Context API al no tener un descripción clara y estándar se hace mucho mas complicado de depurar
Bundle size
Redux necesita de librerías o paquetes externos y requiere ser manualmente integrado para poder ser utilizado
Context API ya viene por defecto integrado y no necesita librerías externas para ser utilizado
Middlewares
Curva de aprendizaje
Rendering
Redux evita render innecesarios
Context API no evita estos render innecesarios, sin embargo, hay técnicas para hacerlo pero se deben hacer manualmente
entiendo que redux es un context con esteroides y mejores state colocations.
4.-Diferencias entre Redux y Context
-- Redux facilita el manejo del estado y lo hace mas predecible y rastreable.
-- React propone Context API:
-- Redux vs Context API
Redux y la API de Contexto son dos soluciones de manejo de estado en React. Ambas tienen sus diferencias y ventajas.
Diferencias: Abstracción: Redux es una librería de terceros más abstracta que la API de Contexto, que es parte de la biblioteca React.
Complejidad: Redux es más complejo que la API de Contexto debido a la necesidad de crear acciones, reductores y un almacén, mientras que la API de Contexto es más sencilla de usar.
Accesibilidad del estado: El estado de Redux está almacenado en un almacén centralizado y se accede a través de la suscripción, mientras que la API de Contexto permite acceder al estado en cualquier parte de la aplicación a través del uso de un Proveedor y un Consumidor.
Ventajas: Redux: Escalabilidad: Redux es muy escalable debido a su estructura de almacén centralizado y reductores. Depuración: Los cambios de estado en Redux son predecibles y fáciles de depurar debido a su estructura y la inmutabilidad del estado. Compatibilidad: Redux es compatible con muchas otras librerías y herramientas debido a su popularidad y amplia comunidad. API de Contexto: Simplicidad: La API de Contexto es mucho más sencilla y fácil de usar que Redux. Integración nativa: La API de Contexto es una parte integral de la biblioteca React, lo que significa que no hay necesidad de instalar dependencias adicionales. Rendimiento: La API de Contexto tiene un rendimiento mejor que Redux debido a su simplicidad y falta de abstracción.
En resumen, Redux y la API de Contexto tienen sus propias ventajas y desventajas. La elección entre ellos depende de las necesidades específicas de la aplicación y de la preferencia personal del desarrollador.
Context API es el mismo useContext?
Estan relacionados. 🤓🍍🍍
useContext() forma parte de la React Context API, pero la Context API es más amplia y engloba aún más funciones que nos permiten compartir valores entre componentes como:
createContext()Context.ProviderSi, exactamente lo mismo que comparte Fernando Alejandro.
Es mas, yo me dirira que en terminos practicos useContext es una forma de utilizar el Context API de manera mucho más facil y rapida. Casi como Redux
Honestamente este es uno de los mayores beneficios que veo en redux, me refiero a evitar a los renders innecesarios. Una vez construí una ecommerce con context y sí noté ese problema de los render, había un pequeño cambio y todos los componentes volvían a renderizarse, cuando la app es pequeña casi ni se nota, pero se vuelve una locura a medida que crece
Context API es la solución que ofrece React para solucionar el problema de props drilling (enviar props de un componente padre hacia los hijos para llegar al quinto nieto). Este problema hace que nuestra aplicación sea complicada de leer y no hace que sea una aplicación mantenible.
ContextAPI nos permite pasar los datos desde los componentes padres a los componentes hijos mediante el árbol de componentes evitando el props drilling. Context esta diseñado para pasar los datos que puedan ser considerados globales.
Cuándo usarlo? Cuando vamos a obtener o generar datos que no son muy cambiantes. Ejemplo: tema de la aplicación (dark o light), lenguaje de la aplicación, booleano del si el usuario está autenticado, etc. Estos pueden ser compatibles con Context ya que pocas veces cambiarán su valor y no requieren de una mayor 'lógica'.
Ya que sabemos los conceptos de Redux, podemos empezar a hacer las comparaciones:
Redux facilita el manejo del estado y lo hace mas predecible y rastreable.
Depuración:
Bundle Size:
Middlewares:
Curva de Aprendizaje:
-Rendering:
INTENCIÓN: APRENDER
Clase 4 — Redux vs Context API
Objetivo: saber cuándo usar cada uno sin dogma. Output: criterio claro + regla práctica para proyectos reales.
La idea central
Redux y Context API resuelven el mismo problema (prop drilling), pero están pensados para niveles de complejidad distintos.
No es “Redux vs Context”. Es Context para simple / Redux para complejo y dinámico.
Comparación directa (lo que importa en la práctica)
🟢 Context API
Usalo cuando:
Ejemplos típicos:
Pros:
Contras reales:
👉 Podés optimizar con memo, useMemo, dividir contextos…
pero ya estás pagando complejidad manual.
🔵 Redux
Usalo cuando:
Ejemplos claros:
Pros:
Contras:
Regla simple para decidir (guardátela)
Si el estado cambia seguido → Redux Si cambia poco y es simple → Context
Si dudás:
Y sí: pueden convivir en el mismo proyecto sin problema.
Punto fino (importante)
Context no es un state manager, es un transportador de datos. Redux sí es un state manager con reglas claras.
Por eso Redux “se siente más pesado”, pero también más predecible.
Mini resumen
Punto ciego habitual
Usar Context “porque Redux es overkill”… y terminar con una app difícil de debuggear.
Ajuste sugerido
En proyectos nuevos: Context para config global + Redux para negocio. Es una combinación muy sana.
Cuando quieras, seguimos con clase 5 (arranca el proyecto) o bajamos esto a un ejemplo concreto tuyo.
⚖️ Redux vs. Context API: ¿Cuál elegir?
Ambas herramientas nacen para solucionar el Prop Drilling: el problema de pasar datos a través de niveles de componentes que no los necesitan solo para llegar a un destino final.
📦 Context API (La solución nativa)
Es ideal para estados "globales" que no cambian frecuentemente.
⚛️ Redux (La solución robusta)
Un sistema profesional para aplicaciones con estados complejos y muy dinámicos.
🔍 Diferencias Clave
💡 Dato interesante: El mito de la exclusividad
Mucha gente cree que debe elegir uno u otro para todo el proyecto, pero la realidad es que pueden coexistir. Puedes usar Context para algo simple como el color de los botones y Redux para la lógica compleja de tu pasarela de pagos.
📝 Ejemplo de decisión
En React, normalmente pasamos datos de componentes padres a componentes hijos mediante propiedades, también llamadas props.
El problema surge cuando los componentes están a varios niveles de distancia, ocasionando el prop drilling, que consiste en pasar propiedades a componentes que no las van a usar, solo para que las reciban y se las transmitan al siguiente hijo, hasta que lleguen al componente destinatario. También surgen problemas si queremos eliminar un componente intermedio, ya que habría que eliminar ese prop de todos los componentes intermedios.
“Cuando un sistema es opaco y determinista, es difícil reproducir errores o agregar nuevas características.”
Sin embargo, React ofrece una solución llamada Context API. A continuación, vamos a comparar y analizar sus diferencias con Redux.
Context API
La Context API nos proporciona una forma de pasar datos de los componentes padres a los componentes hijos a través del árbol de componentes sin necesidad de hacerlo manualmente en cada nivel. Está diseñada para compartir datos que pueden considerarse globales.
Se recomienda utilizarla cuando necesitamos acceder o usar datos que no cambian con frecuencia durante la ejecución de la aplicación, como por ejemplo los datos del usuario autenticado. La Context API está disponible a partir de la versión 16.3 de React.
Diferencias entre Context API y Redux
Código con Context API
import Sparkles from "./components/Sparkles"; import Adder from "./components/Adder"; import Remover from "./components/Remover"; import "./styles.css"; export default function App() { return ( <div className="App"> <h1>Context vs. Redux</h1> <section> <Sparkles /> </section> <section> <Adder /> <Remover /> </section> </div> );
import { useContext } from "react"; import { GeneralContext } from "../context/generalContex"; export default function Sparkles() { const { state } = useContext(GeneralContext); const counter = state.sparkles; const sparklesArray = Array(counter).fill("✨"); console.log("Render sparkles..."); return <p className="Sparkles">{sparklesArray.join(" ")}</p>; } import { useContext } from "react"; import { REMOVE_SPARKLE } from "../actions/types"; import { GeneralContext } from "../context/generalContex"; export default function Remover() { const { dispatch } = useContext(GeneralContext); const handleOnclick = () => { dispatch({ type: REMOVE_SPARKLE }); }; console.log("Render Remover..."); return ( <button className="Remover" onClick={handleOnclick}> Remover </button> ); } import { useContext } from "react"; import { ADD_SPARKLE } from "../actions/types"; import { GeneralContext } from "../context/generalContex"; export default function Adder() { const { dispatch } = useContext(GeneralContext); const handleOnclick = () => { dispatch({ type: ADD_SPARKLE }); }; console.log("Render Adder..."); return ( <button className="Adder" onClick={handleOnclick}> Agregar </button> ); }
Básicamente, tenemos tres componentes: Sparkles, Adder y Remover. Cada uno incluye un console.log que indica cuándo se renderiza. Podemos observar que, en el primer render, se renderizan los tres componentes.
import React, { createContext, useReducer } from "react"; import generalReducer from "../reducers/generalReducer"; const initialState = { sparkles: 1 }; export const GeneralContext = createContext(initialState); export const GeneralProvider = ({ children }) => { const [state, dispatch] = useReducer(generalReducer, initialState); return ( <GeneralContext.Provider value={{ state, dispatch }}> {children} </GeneralContext.Provider> ); };
import { ADD_SPARKLE, REMOVE_SPARKLE } from "../actions/types"; const generalReducer = (state, action) => { switch (action.type) { case ADD_SPARKLE: return { ...state, sparkles: state.sparkles + 1 }; case REMOVE_SPARKLE: return { ...state, sparkles: state.sparkles >= 1 ? state.sparkles - 1 : 0 }; default: return state; } }; export default generalReducer;
Con Context API, al cambiar el estado mediante los botones de Agregar o Remover, los tres componentes se re-renderizan. En teoría, los botones no sufrieron ningún cambio, por lo que no sería necesario renderizarlos nuevamente.
Código con Redux
import { useSelector } from "react-redux"; export default function Sparkles() { const sparkles = useSelector((state) => state.sparkles); const sparklesArray = Array(sparkles).fill("✨"); console.log("Render Sparkles..."); return <p className="Sparkles">{sparklesArray.join(" ")}</p>; } import { useDispatch } from "react-redux"; import { ADD_SPARKLE } from "../actions/types"; export default function Adder() { const dispatch = useDispatch(); const handleOnclick = () => { dispatch({ type: ADD_SPARKLE }); }; console.log("Render Adder..."); return ( <button className="Adder" onClick={handleOnclick}> Agregar </button> ); } import { useDispatch } from "react-redux"; import { REMOVE_SPARKLE } from "../actions/types"; export default function Remover() { const dispatch = useDispatch(); const handleOnclick = () => { dispatch({ type: REMOVE_SPARKLE }); }; console.log("Render Remover..."); return ( <button className="Remover" onClick={handleOnclick}> Remover </button> ); }
import { ADD_SPARKLE, REMOVE_SPARKLE } from "../actions/types"; const initialState = { sparkles: 1 }; const generalReducer = (state = initialState, action) => { switch (action.type) { case ADD_SPARKLE: return { ...state, sparkles: state.sparkles + 1 }; case REMOVE_SPARKLE: return { ...state, sparkles: state.sparkles >= 1 ? state.sparkles - 1 : 0 }; default: return state; } }; export default generalReducer;
Teniendo la misma estructura de proyecto, pero utilizando Redux, podemos ver que creamos nuestro store y lo conectamos al Provider.
import ReactDOM from "react-dom"; import { createStore } from "redux"; import { Provider } from "react-redux"; import generalReducer from "./reducers/generalReducer"; import App from "./App"; const store = createStore(generalReducer); const rootElement = document.getElementById("root"); ReactDOM.render( <Provider store={store}> <App /> </Provider>, rootElement );
Podemos observar que, en el primer render, los tres componentes se renderizan. Sin embargo, al cambiar el estado mediante los botones de Agregar o Remover, solo se re-renderiza el componente que realmente cambió, que en este caso es Sparkles.
En proyectos pequeños y sencillos, los problemas de rendimiento no son tan evidentes. Pero en aplicaciones más complejas, con un árbol de componentes más profundo, sí puede afectar la experiencia del usuario. Context API no siempre presenta este problema, ya que existen técnicas para evitar re-renders innecesarios. Sin embargo, Redux ya incluye estas optimizaciones de forma nativa.
En Context API por qué se genera el re-renderizado?
Es el comportamiento por defecto al usar context
When the value in Context Provider changes, all components that use this Context will re-render, even if they don’t use the changed portion of the data directly. Those re-renders can not be prevented with memoization directly, but there are a few workarounds that can simulate it (see Part 7: preventing re-renders caused by Context).
Te invito a tomar esta lectua que nos explica cuándo puede pasar los re renders innecesarios: https://www.developerway.com/posts/react-re-renders-guide
De por si ya me cuesta entender context, se como funciona pero al momento de utilizarlo tengo que ver siempre la documentation porque no me lo se paso a paso.
Me interesa saber que tanto de redux hay en zustand