Divide contextos, proveedores memoizados y patrones selectores para evitar tormentas de re-renderizado. React Context está incorporado y funciona para valores que cambian raramente - tema, idioma, sesión de autenticación. Un único mega-contexto que se actualiza cada segundo hundirá el rendimiento del scroll de listas en dispositivos Android de gama media.
React re-renderiza todos los consumidores de un contexto cuando la identidad de Provider value={...} o contenido dispara una actualización. Un error común:
// - Nuevo objeto en cada renderizado - todos los consumidores re-renderizados<AppContext.Provider value={{ user, cart, theme, setTheme }}>
Aunque solo cart cambió, los consumidores de theme se re-renderizarán porque el objeto value es nuevo.
Contexto único con { state, dispatch, extras } - Cada dispatch re-renderiza lectores de extras. Solución: Divide estado y acciones.
Funciones inline en el valor del proveedor - signOut: () => setUser(null) rompe React.memo. Solución:useCallback.
Almacenar arrays traídos en Context - Las actualizaciones de refetch re-renderizarán el árbol. Solución: TanStack Query.
Proveedor dentro de FlatList renderItem - N proveedores por fila. Solución: Un proveedor en app/_layout.tsx.
Valor de contexto predeterminado con datos reales - createContext({ user: guest }) enmascara el proveedor faltante. Solución:null + throw en hook.
Selector useSyncExternalStore sin suscripción de almacén - El ejemplo anterior aún re-renderiza cuando el contexto padre se actualiza - las necesidades verdaderamente de grano fino requieren almacén externo (Zustand/Jotai).
Pasar cliente API completo en Context - Estable pero fomenta contexto gordo. Solución: Singleton de módulo o DI - ver inyección de dependencias.
Context es rápido - los consumidores innecesarios son lentos. Divide contextos, memoiza valores y evita poner estado de alta frecuencia en Context.
¿Cuántos proveedores en root es demasiado?
Tres a cinco proveedores bien clasificados es normal (Query, Session, Theme, SafeArea). Más de ocho anidados sugiere consolidación.
¿Debo usar Context para el tema de React Navigation?
Expo Router / React Navigation aceptan una prop theme en el navegador root - a menudo más simple que Context personalizado solo para colores.
¿Context vs Zustand para auth?
Ambos funcionan. Context + adaptador expo-secure-store es común. Zustand ayuda cuando muchos selectores leen banderas de UI adyacentes a auth - ver Decisión ADR 7.
¿Cómo pruebo proveedores?
Envuelve con SessionProvider en pruebas; mock almacén seguro en límite. Prefiere probar hooks con renderHook y valores de contexto stubbed.
¿React 19 mejora Context?
React 19 continúa con renderizado concurrente - los consumidores de contexto aún se re-renderizarán cuando el valor cambia. Dividir y selectores siguen siendo práctica recomendada en RN 0.86.
¿Puedo combinar useReducer con Context?
Sí - useReducer en proveedor, dividir dispatch en contexto de acciones. El patrón coincide con Redux sin la dependencia.
¿Qué hay de React.memo en elementos de lista?
Memo ayuda solo si las props son estables. Soluciona el proveedor primero - memo en 200 filas es una tirita en una tormenta.
¿Debería vivir locale en Context?
Sí - la dirección de i18n y las cadenas cambian con poca frecuencia. Empareja con expo-localization para valor predeterminado del dispositivo; persiste personalización del usuario en AsyncStorage.
¿Cómo depuro tormentas de re-renderizado?
Perfilador de React DevTools - grabar interacción - encontrar renderizados en cascada desde un proveedor de contexto. Voltea una división a la vez.
¿Es pasar dispatch vía Context está bien?
dispatch es estable - seguro en contexto de acciones. Los consumidores que solo despachan nunca necesitan contexto de estado.
¿Cuándo es un contexto combinado aceptable?
Prototipos y aplicaciones con <10 pantallas donde el perfilador no muestra jank de lista. Refactoriza antes de enviar listas largas.