Quando Usar Context API: State Built-in React
Quando Context é suficiente e quando precisa de state library externa.
Por que isso é importante
Quando Usar Context API: State Built-in React. Quando Context é suficiente e quando precisa de state library externa.
Quando SIM usar Context API
Dados globais que mudam raramente
Theme, locale, user auth. Mudam uma vez por sessão. Re-renders não importam. Context é perfeito e zero libs externas.
Você quer evitar prop drilling simples
Passar props por 3-4 níveis é chato. Context elimina isso. Se você não precisa de lib externa, Context resolve.
App é pequeno (<10 componentes usando state)
Overhead de Redux/Zustand não compensa. Context é suficiente. Simplicidade vence.
Você está prototipando ou fazendo MVP
Velocidade importa mais que otimização. Context é built-in, setup zero. Otimiza depois se necessário.
State é read-heavy, write-rare
Config da app, feature flags. Escrito no início, lido sempre. Context não penaliza isso.
Quando NÃO usar Context API
State muda frequentemente
Formulários, UI state, typing indicators. Cada update re-renderiza todos consumers. Performance despenca. Use Zustand/Redux.
Você precisa de memoização granular
Context re-renderiza tudo. Zustand tem selectors. Se só 1 campo mudou mas 10 componentes re-renderizam, Context é problema.
Debugging de state flow é importante
Context não tem DevTools. Debugar quem mudou o quê é difícil. Redux DevTools dá visibilidade total.
App vai crescer significativamente
Context funciona pequeno mas vira bagunça grande. Se app vai escalar, invista em state library desde cedo.
Otimizando Context
Split contexts por responsabilidade
ThemeContext separado de UserContext. Mudança em theme não re-renderiza componentes de user. Isolamento reduz re-renders.
Use useMemo pra value do Context
Context value deve ser memoizado. Sem memo, cada render do provider cria objeto novo. Todos consumers re-renderizam.
Combine com useReducer pra logic
useReducer + Context = mini-Redux. Padrão mais estruturado. Melhor que useState solto quando logic cresce.
Framework de Decisão
Checklist pra usar Context API
- Dados mudam raramente (< 1 vez/minuto)?
- App tem menos de 10 componentes usando state?
- Você quer evitar libs externas?
- Performance de re-render não é crítica?
- State é read-heavy, não write-heavy?
- App não vai crescer massivamente?
4+ sim: Context resolve. 2-3: considere Zustand se houver crescimento. 0-1: use Zustand ou Redux.
Regra Prática
Use Context pra config, theme, auth. Use Zustand/Redux pra UI state, formulários, dados que mudam frequente. Combine ambos conforme natureza do state.
Perguntas frequentes
Quando SIM usar Context API
Theme, locale, user auth. Mudam uma vez por sessão. Re-renders não importam. Context é perfeito e zero libs externas. Passar props por 3-4 níveis é chato. Context elimina isso. Se você não precisa de lib externa, Context resolve. Overhead de Redux/Zustand não compensa. Context é suficiente. Simplicidade vence.
Quando NÃO usar Context API
Formulários, UI state, typing indicators. Cada update re-renderiza todos consumers. Performance despenca. Use Zustand/Redux. Context re-renderiza tudo. Zustand tem selectors. Se só 1 campo mudou mas 10 componentes re-renderizam, Context é problema. Context não tem DevTools. Debugar quem mudou o quê é difícil. Redux DevTools dá visibilidade total.