Quando Usar Context API: State Built-in React
Quando Context é suficiente e quando precisa de state library externa.
Carregando
Quando Context é suficiente e quando precisa de state library externa.
Quando Usar Context API: State Built-in React. Quando Context é suficiente e quando precisa de state library externa.
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.
Velocidade importa mais que otimização. Context é built-in, setup zero. Otimiza depois se necessário.
Config da app, feature flags. Escrito no início, lido sempre. Context não penaliza isso.
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.
Context funciona pequeno mas vira bagunça grande. Se app vai escalar, invista em state library desde cedo.
ThemeContext separado de UserContext. Mudança em theme não re-renderiza componentes de user. Isolamento reduz re-renders.
Context value deve ser memoizado. Sem memo, cada render do provider cria objeto novo. Todos consumers re-renderizam.
useReducer + Context = mini-Redux. Padrão mais estruturado. Melhor que useState solto quando logic cresce.