¿Cuándo es Context una buena solución de estado y cuándo no?

Question

Accepted Answer

La **Context API** de React te permite compartir un valor con un subárbol completo de componentes sin prop drilling. Es excelente para datos **de baja frecuencia, ampliamente compartidos** — pero *no* es una solución completa de state-management y tiene una trampa de re-renderizado para estados que cambian frecuentemente. ## Cuándo Context brilla ```jsx const ThemeContext = createContext("light"); function App() { const [theme, setTheme] = useState("light"); return ( {/* any descendant can read theme — no prop drilling */} ); } ``` ```text Good fits (data that's read widely but changes rarely): ✓ Theme (dark/light) ✓ Current user / auth ✓ Locale / i18n ✓ App-wide config or feature flags ``` ## La trampa: cada consumidor se re-renderiza en CUALQUIER cambio ```jsx // ❌ a context value that changes often re-renders ALL consumers const AppContext = createContext(); // value = { user, cart, notifications, ...everything } // → updating ONE field re-renders EVERY component using the context ``` Cuando el valor del contexto cambia, **todos** los componentes que consumen ese contexto se re-renderizan — sin importar si usan la parte que cambió. Para estado que se actualiza frecuentemente, esto causa problemas de rendimiento. Context no tiene suscripción selectiva integrada. ## Mitigaciones y la alternativa ```text ✓ Split into multiple focused contexts (ThemeContext, UserContext separately) ✓ Memoize the value object (useMemo) so it doesn't change identity needlessly ✗ But for high-frequency or large shared state → use a real store ``` Las librerías de estado (Zustand, Redux, Jotai) resuelven el problema de re-renderizado con **suscripciones selectivas** — los componentes se suscriben solo a los slices que usan y se re-renderizan solo cuando esos cambian: ```js const count = useStore(s => s.count); // re-renders ONLY when count changes ``` ## Context no es un gestor de estado ```text Context = a TRANSPORT mechanism (passes a value down), NOT state management itself. You still need useState/useReducer to hold the state; Context just distributes it. ``` ## Por qué es importante Conocer el punto fuerte de Context — y sus límites — previene dos errores comunes: hacer prop-drilling de cosas que deberían estar en Context, y poner estado de alta frecuencia en Context (causando re-renderizados en toda la aplicación). La regla: Context para valores **que cambian raramente, ampliamente compartidos** (theme, user, locale); una store dedicada con suscripciones selectivas para estado compartido **que cambia frecuentemente o es grande**. Entender que Context distribuye estado pero no lo gestiona aclara cuándo es suficiente y cuándo necesitas algo más.