Perguntas de Entrevista

A.React.memo memoiza o COMPONENTE inteiro (evita re-render). useMemo memoiza um VALOR computado (cache de cálculo). useCallback memoiza uma FUNÇÃO (mantém a mesma referência entre renders). Os três usam comparação rasa por padrão.ver conceito →

A.Não. Tem custo próprio (a comparação roda a cada render do pai). Se o componente é trivial ou recebe props sempre diferentes, memo piora a performance. Sempre meça com React Profiler antes de aplicar.ver conceito →

A.Comparação por referência (===) para objetos/arrays e por valor para primitivos. { a: 1 } === { a: 1 } é false (referências diferentes), mas 1 === 1 é true.ver conceito →

A.useTransition é o hook que retorna [isPending, startTransition]. O isPending permite mostrar feedback visual (spinner, opacity). startTransition (sem hook) é a função pura, usada quando você não precisa de feedback.ver conceito →

A.Não totalmente. Debounce ATRASA a execução. startTransition EXECUTA imediatamente mas em prioridade baixa, podendo ser interrompido. Para network calls (API), debounce ainda é melhor. Para filtros locais pesados, startTransition é mais responsivo.ver conceito →

A.Porque o usuário precisa ver o caractere imediatamente. Marcar como não-urgente faria a UI parecer travada. Inputs controlados sempre devem ser updates urgentes.ver conceito →

A.O servidor lê via cookies() do next/headers e passa o valor como prop para o Client Component. Cookies HttpOnly não são acessíveis no client mesmo — precisam vir do servidor.ver conceito →

A.Não. Server Components não têm hooks de estado (useState, useEffect, useReducer, useContext). São completamente sem estado e renderizados apenas uma vez no servidor.ver conceito →

A.typeof window === 'undefined' indica servidor. Mas em RSC isso é desnecessário — o tipo de componente é definido na arquitetura ('use client' ou ausência dele), não em runtime.ver conceito →

A.useTransition quando você CONTROLA o setState (envolve a chamada). useDeferredValue quando recebe o valor de fora (props, contexto) e não pode envolver o setState.ver conceito →

A.Estado visual inconsistente onde diferentes partes do componente mostram valores de versões diferentes do estado durante renders concorrentes. O Concurrent Mode pode interromper renders, e sem cuidado, partes podem ficar 'rasgadas'.ver conceito →

A.Pra renders pesados sim, é melhor. Pra calls de API ainda use debounce — useDeferredValue não atrasa execução, só prioriza.ver conceito →

A.Componentes filhos 'lançam' uma Promise (throw promise). Suspense captura via try/catch interno do React e renderiza o fallback até a Promise resolver. Libs como React Query e RSC fazem isso por baixo dos panos.ver conceito →

A.Não diretamente. Suspense precisa de uma fonte que 'suspenda' (lance Promise). Para useEffect tradicional, você implementa loading manual. Para Suspense, use libs (React Query, SWR, Relay) ou RSC.ver conceito →

A.Suspense só lida com loading. Pra erros, combine com ErrorBoundary. O padrão é: <ErrorBoundary><Suspense fallback={...}>...</Suspense></ErrorBoundary>ver conceito →

A.Quando a função não é passada como prop para componentes memoizados, nem é dependência de outro hook. Em handlers locais (onClick), useCallback é puro overhead.ver conceito →

A.Sim. React Compiler (ex-React Forget) memoiza automaticamente componentes e hooks em compile-time. Quando estável, useMemo/useCallback manuais se tornarão raros.ver conceito →

A.React DevTools Profiler. Compare 'tempo de render' antes e depois. Se as props nunca mudam de valor mas mudam de referência, memo ajuda. Se mudam sempre, memo só adiciona custo.ver conceito →

A.Sim, por padrão. {variavel} sempre escapa HTML automaticamente. <script> em string vira texto literal. Apenas dangerouslySetInnerHTML, eval(), e injeções via href/src bypassam isso.ver conceito →

A.Content Security Policy é um header HTTP que restringe quais scripts/recursos podem executar. CSP bem configurada bloqueia XSS mesmo se a sanitização falhar — defesa em camadas.ver conceito →

A.1) Stored (script salvo no banco e renderizado para todos), 2) Reflected (script via URL params refletido), 3) DOM-based (manipulação client-side perigosa). DOMPurify protege contra todos.ver conceito →

A.react-window é a versão moderna, mais leve e simples (mesmo autor). react-virtualized tem mais features (grid, masonry) mas é maior. Para 90% dos casos, use react-window.ver conceito →

A.Negativamente — só os itens visíveis estão no DOM. Para listas que precisam ser indexadas (ex: produtos), prefira paginação tradicional ou SSR sem virtualização. Use virtualização apenas em listas internas/dashboards.ver conceito →

A.react-window oferece VariableSizeList. TanStack Virtual mede automaticamente. A lógica é mais complexa — precisa do tamanho de cada item antes de renderizar (ou medir dinamicamente).ver conceito →

A.O exhaustive-deps quer que todas as variáveis externas usadas no effect estejam declaradas nas deps. [] indica 'rodar só uma vez' mas se o effect usa props/state, eles podem ficar stale (desatualizados).ver conceito →

A.Quando o effect realmente não depende de nenhum valor externo: setup de subscriptions globais, listeners do window/document, inicialização de bibliotecas. Mesmo assim, certifique-se que callbacks dentro são estáveis.ver conceito →

A.Em StrictMode (dev), effects rodam duas vezes para detectar bugs. Não tente 'evitar' — ajuste o cleanup para ser idempotente. Em produção, roda apenas uma vez.ver conceito →

A.Reduz TTFB (server pode começar a responder antes de todos os dados). Reduz FCP (browser pinta a primeira parte rapidamente). Não afeta LCP diretamente, mas melhora a percepção de carregamento.ver conceito →

A.Hidratação seletiva: o React 18 hidrata partes da página independentemente, conforme cada chunk chega. Permite o usuário interagir com a parte de cima enquanto o resto ainda hidrata.ver conceito →

A.Precisa de runtime que suporte HTTP streaming. Vercel, Cloudflare, Netlify suportam. Alguns CDNs/proxies fazem buffering e quebram o streaming — verifique a documentação do seu host.ver conceito →

A.React DevTools Profiler → 'Record why each component rendered'. Se aparece 'Props changed: ' com props que poderiam ser estáveis, memo + estabilizar refs ajuda. Se 'Hooks changed' ou 'Parent rendered', memo não resolve.ver conceito →

A.Se children for JSX inline, sim — JSX é objeto novo a cada render. Solução: passar children memoizados via useMemo, ou usar context para evitar passar via props.ver conceito →

A.Frequentemente sim. Use só quando profiling mostra ganho real. Em apps pequenos/médios, geralmente não há diferença perceptível e o código fica mais difícil de ler.ver conceito →

A.react-hook-form usa refs (uncontrolled), evitando re-render por keystroke. Formik usa state controlado, re-render em cada digitação. RHF é significativamente mais performático em forms grandes.ver conceito →

A.Validação com schema (Zod, Yup) executa apenas no submit ou onBlur. Validações que precisam ser em tempo real podem ser debouncadas. Em RHF: mode: 'onBlur' ou 'onSubmit'.ver conceito →

A.Quando os campos têm dependências entre si (mudar A reseta B). useReducer centraliza a lógica e evita múltiplos useState entrelaçados.ver conceito →

A.Não. Cada render gera key diferente, fazendo o React destruir e recriar todos os componentes. Estado é perdido, animações reiniciam, performance é péssima. Use IDs estáveis.ver conceito →

A.Lista 100% estática (nunca reordena, adiciona ou remove), e os itens não têm estado interno (input, animação, etc). Em qualquer outro caso, prefira ID.ver conceito →

A.Não é passada para o componente filho — é usada apenas pelo React internamente. Por isso props.key dentro do componente é undefined. É um identificador no contexto do array.ver conceito →

A.Sim, sem problemas. O Server Component renderiza o HTML inicial e o Client Component é hidratado depois no browser.ver conceito →

A.Não diretamente. Mas pode RECEBER Server Components como children (props). Padrão: <ClientWrapper><ServerComp /></ClientWrapper> funciona.ver conceito →

A.Não. Zero JS do componente vai para o browser. Apenas o HTML resultante. Por isso libs pesadas (markdown, charts complexos) usadas só no server reduzem o bundle do cliente.ver conceito →

A.actualDuration é o tempo real do render (com memoização). baseDuration é o tempo SEM memoização (re-renderizando tudo). A diferença mostra quanto a memoização está economizando.ver conceito →

A.Use Web Vitals (LCP, INP, CLS) via web-vitals lib enviando para analytics. Profiler é para development. Em produção, Real User Monitoring (RUM) é o caminho.ver conceito →

A.Build de produção remove a Profiler API por padrão. Para habilitar, use o build especial com profiling enabled (React docs explicam). Não recomendado em produção real.ver conceito →

A.Porque qualquer mudança cria novo array (referência nova), causando re-render de todos os componentes que dependem dele. Mapas/objetos por ID permitem updates granulares.ver conceito →

A.O hook useStore aceita um seletor: useStore(s => s.byId[id]). Apenas re-renderiza quando esse pedaço específico do estado muda, comparado por Object.is.ver conceito →

A.WebSocket: bidirecional, baixa latência, ideal para chat/dashboards live. Polling/SSE: mais simples, funciona em qualquer infra. Para Next.js, Server-Sent Events (SSE) costuma ser suficiente para a maioria dos casos.ver conceito →

A.Não — não há DOM no servidor. React mostra warning. Use a custom: useIsomorphicLayoutEffect (= useLayoutEffect no client, useEffect no server). Ou simplesmente o componente que usa useLayoutEffect deve ser Client Component.ver conceito →

A.Pode bloquear o paint se for muito pesado, causando lag visível. Use só quando necessário e mantenha o código rápido. Para operações longas, prefira useEffect.ver conceito →

A.Sim: requestAnimationFrame ou useEffect com setTimeout(0). Útil para tracking, analytics, ou qualquer coisa que não deve bloquear o paint.ver conceito →

A.React.lazy é a API padrão do React, funciona em qualquer app. next/dynamic é o wrapper do Next.js que adiciona: SSR opcional (ssr: false), loading fallback, e suporte a named exports.ver conceito →

A.Carregar o chunk antes do usuário precisar. Next.js Link prefetch (faz auto em hover/viewport). Pode ser manual com import() em handlers.ver conceito →

A.Por rota é mais simples e geralmente suficiente. Por componente faz sentido para componentes pesados raramente usados (modais complexos, editores, charts).ver conceito →

A.Worker: thread por aba. SharedWorker: compartilhado entre abas da mesma origem. Service Worker: roda em background mesmo sem aba aberta, intercepta requests (PWA, offline).ver conceito →

A.Sim. Comlink (Google) abstrai postMessage/onmessage em chamadas async normais. Você chama worker.heavyFunc(data) como se fosse local, e ele lida com a comunicação por baixo.ver conceito →

A.Sim, fetch funciona em Workers. Útil para descarregar parsing de respostas grandes (JSON gigante, CSV, etc.) sem travar a UI.ver conceito →

A.Fiber é a arquitetura do React 16+ que reescreveu o reconciliador. Permite renderização interrompível (Concurrent Mode), priorização de updates, e suspense. O Virtual DOM continua, mas o algoritmo de processamento mudou completamente.ver conceito →

A.Para o algoritmo de diffing identificar qual item é qual entre renders. Sem keys, React reconcilia por posição (index), o que falha quando itens são reordenados.ver conceito →

A.Não necessariamente. Para mudanças simples e localizadas, DOM direto é mais rápido. O Virtual DOM ganha em UIs complexas com muitas atualizações em cascata, onde calcular o mínimo necessário é crucial.ver conceito →

A.Para simplicidade e performance. Com a regra de 'mesma ordem sempre', React mantém apenas um array de estados internos por componente. Sem essa regra, precisaria de identificação por nome (mais lento e verboso).ver conceito →

A.Não. Hooks só em funções de componentes ou em outros hooks customizados. Em handlers, use o estado/setter retornado pelo hook chamado no topo.ver conceito →

A.Mover a condição PARA DENTRO do hook. Ex: useEffect(() => { if (cond) doStuff(); }, [cond]). NÃO: if (cond) useEffect(...).ver conceito →

A.Não. Cada chamada de um custom hook em um componente diferente tem estado independente. Para compartilhar estado, use Context, Zustand, Redux ou outra solução de state management.ver conceito →

A.Quando a mesma lógica stateful aparece em 2+ componentes. Ou quando um componente fica difícil de ler com muitos hooks misturados — extrair para custom hook melhora legibilidade.ver conceito →

A.Sim, hooks compõem. useUser pode chamar useFetch que chama useState e useEffect. As Rules of Hooks valem em toda a cadeia.ver conceito →

A.useState: 1-3 valores independentes. useReducer: 4+ valores relacionados, ou quando o próximo state depende complexamente do anterior, ou quando você quer testar a lógica de transição isoladamente.ver conceito →

A.Para apps pequenos/médios, sim. Para apps grandes, Redux Toolkit oferece DevTools, middleware, slices, e melhor performance com seletores. A escolha depende da escala.ver conceito →

A.Para previsibilidade e testabilidade. Side effects (fetch, localStorage) devem ficar em useEffect ou middleware (no caso de Redux). Reducer puro = mesma input → mesmo output.ver conceito →

A.Quando o value do Provider muda, TODOS os componentes que usam useContext re-renderizam, mesmo que só usem parte do valor. Solução: dividir em múltiplos contexts ou usar libs como use-context-selector.ver conceito →

A.Context: ideal para valores que raramente mudam (tema, idioma, usuário). Redux/Zustand: para state que muda frequentemente, com seletores otimizados que evitam re-renders desnecessários.ver conceito →

A.1) Estabilizar value com useMemo. 2) Dividir contexts (ThemeContext separado de UserContext). 3) Usar libs como use-context-selector que permitem seletores. 4) Memoizar componentes consumidores.ver conceito →

A.useRef: valores que não afetam a renderização (timers, contadores internos, refs DOM). useState: valores que, quando mudam, devem re-renderizar a UI.ver conceito →

A.Por padrão, refs não passam para componentes funcionais (props.ref é undefined). forwardRef envolve o componente para receber e repassar refs. Necessário para componentes de biblioteca (Button, Input, etc).ver conceito →

A.Customiza o que o ref do componente expõe ao pai. Em vez de expor o DOM bruto, você expõe métodos específicos (focus, scrollIntoView, validate). Melhora encapsulamento.ver conceito →

A.Os métodos componentDidCatch e getDerivedStateFromError são lifecycle de class. Hooks ainda não têm equivalente direto. Use a lib react-error-boundary para uma API com hooks por baixo.ver conceito →

A.1) Erros em event handlers (use try/catch). 2) Async (Promises rejeitadas, fetch). 3) SSR (use error.tsx no Next.js). 4) Erros no próprio Error Boundary. 5) Erros de hidratação (parcialmente).ver conceito →

A.error.tsx em cada rota cria um Error Boundary automático. global-error.tsx para o root. not-found.tsx para 404. Esses arquivos precisam ser Client Components ('use client').ver conceito →

A.Portal mantém a relação React (props, context, refs). Se você renderizar fora, perde acesso a contexts e props. Portal é o melhor dos dois mundos.ver conceito →

A.Sim, no React. Um onClick no parent React captura cliques do portal, mesmo o portal estando em document.body. No DOM nativo não, mas o React simula isso.ver conceito →

A.Geralmente <div id='modal-root'> no public/index.html ou layout.tsx, fora da div principal do app. Permite z-index alto sem conflitos.ver conceito →

A.Para detectar effects sem cleanup adequado. React simula: monta → desmonta → monta novamente. Se cleanup está correto, comportamento é idêntico. Se não, você verá problemas (subscriptions duplicadas, etc).ver conceito →

A.Não. Em build de produção, StrictMode não tem efeito. Os 'avisos' e duplicações são apenas em desenvolvimento.ver conceito →

A.NÃO 'fugir' do StrictMode — corrigir o código. Effects devem ter cleanup. Initializers do useState devem ser puros. APIs como AbortController para cancelar fetches duplicados.ver conceito →

A.Console mostra qual elemento difere. Causas comuns: 1) new Date() inline. 2) typeof window check incorreto. 3) localStorage no render. 4) Componentes que dependem de viewport. 5) Math.random() para keys.ver conceito →

A.Sim. useId gera IDs estáveis entre server e client (sequência baseada na árvore React), evitando mismatch ao usar IDs em labels, ARIA, etc.ver conceito →

A.Com Suspense + Streaming, partes podem ser hidratadas independentemente. Mismatch em uma parte não quebra a página inteira — apenas aquele boundary é re-renderizado client-side.ver conceito →

A.useSyncExternalStore: quando o valor vem de fora do React (window.matchMedia, BroadcastChannel, custom store). useEffect+useState: para values que estão no React e mudam por setState.ver conceito →

A.Subscribe = adiciona listener; getSnapshot = retorna mql.matches atual; getServerSnapshot = false (server não tem viewport). Hook retorna boolean reativo.ver conceito →

A.Use a versão useSyncExternalStoreWithSelector (do react-server-utils ou Redux). Permite memoizar partes do store, evitando re-renders desnecessários.ver conceito →

A.useId: ID determinístico baseado na árvore React, igual server/client, ideal para a11y. UUID: aleatório, único globalmente, ideal para keys de banco/dados, mas causa mismatch em SSR.ver conceito →

A.Sim. Padrão comum: const id = useId(); depois id+'-name', id+'-email' para múltiplos campos relacionados ao mesmo formulário.ver conceito →

A.Sim, perfeitamente. Foi feito para isso. App Router gera IDs estáveis entre Server Component render e client hydration.ver conceito →

A.1) Forms grandes onde performance importa. 2) Integração com libs não-React. 3) File inputs (sempre uncontrolled — não dá pra setar value programaticamente). 4) Inputs onde você só precisa do valor no submit.ver conceito →

A.No submit ou onBlur, leia ref.current.value e valide. Bibliotecas como react-hook-form abstraem isso elegantemente, dando você a API de controlled mas com performance de uncontrolled.ver conceito →

A.defaultValue só é lido no primeiro render. Mudanças posteriores são ignoradas — esse é o comportamento de uncontrolled. Se precisa atualizar, é controlled (use value).ver conceito →

A.Lifting: ideal para 2-3 níveis. Mais explícito, melhor para refactor. Context: bom para muitos níveis ou quando muitos componentes consomem. Trade-off: explicitness vs convenience.ver conceito →

A.Quando o state sobe demais (5+ níveis) e polui componentes que não usam. Quando muitos componentes em locais distantes precisam acessar — Context, Zustand ou Redux são melhores.ver conceito →

A.Memoize callbacks com useCallback ao passar para filhos memoizados. Considere splitting de state — partes que mudam frequentemente vs partes estáveis em diferentes lugares.ver conceito →

A.SSG é gerado UMA vez no build — para atualizar precisa rebuildar. ISR regenera sob demanda em background, com tempo de revalidate. Usuário sempre recebe versão cacheada (rápido) e o background atualiza.ver conceito →

A.Sim — SSR exige servidor processando a cada request. Mas SSR + Streaming + cache de dados pode chegar perto. Para dados muito dinâmicos (per-user), SSR é necessário.ver conceito →

A.Dado muda raramente e é igual para todos? SSG. Muda toda hora mas é igual? ISR (revalidate). Per-user ou tempo real? SSR. App interativo sem SEO? CSR.ver conceito →

A.Server Action: para mutações usadas apenas pelo seu app (tightly-coupled, segura). Route Handler: para APIs públicas, webhooks, integrações com terceiros, GET endpoints.ver conceito →

A.revalidatePath('/path') invalida o cache de uma página específica. revalidateTag('tag') invalida fetches com aquela tag. Combinado com fetch's next.tags, controle granular de cache.ver conceito →

A.Sim, qualquer JSON serializável. Útil para retornar erros de validação, IDs criados, etc. O cliente recebe via async/await.ver conceito →

A.revalidatePath('/posts') ou revalidateTag('posts') em Server Actions/Route Handlers. Ou definir time-based via { next: { revalidate: 60 } } no fetch.ver conceito →

A.Cache client-side do payload RSC. Quando você navega para uma rota e volta, o Next.js usa o cache em vez de buscar de novo. Configurável via staleTimes em next.config.js.ver conceito →

A.Memoiza chamadas a funções server-side (DB, computações) com TTL e tags. Útil para cache de queries que não usam fetch, como Prisma queries.ver conceito →

A.Edge: middleware, autenticação, redirects, geo-routing, cabeçalhos. Node: queries com Prisma/Drizzle, libs nativas (sharp, puppeteer), uploads grandes, integrações com APIs antigas.ver conceito →

A.Apenas com Prisma Accelerate (proxy). Drivers diretos (PostgreSQL, MySQL) não rodam em Edge. Drizzle com Neon/PlanetScale serverless drivers funciona.ver conceito →

A.export const runtime = 'edge' no top do arquivo da rota/middleware. 'nodejs' é o default. Middleware é sempre Edge.ver conceito →

A.SSR streaming: tudo é gerado a cada request (mesmo o shell). PPR: shell estático cached em CDN, apenas o dinâmico é gerado por request. PPR é mais rápido para o shell.ver conceito →

A.Páginas onde quase tudo é dinâmico (não há shell estático real) ou onde o shell muda muito por user. Aí SSR puro é mais simples.ver conceito →

A.experimental: { ppr: true } em next.config.js + export const experimental_ppr = true no layout/page. Versões mais novas podem ter API estável.ver conceito →

A.Middleware: bloqueia ANTES de carregar a rota (mais rápido para deny). Server Component: pode ler cookies/headers e fazer redirect, mas o componente já começou a renderizar. Use middleware para auth simples, Server Component para lógica complexa.ver conceito →

A.Sim, antes deles. Middleware → Server Component → Client Component. Headers/cookies modificados no middleware estão disponíveis nos Server Components via headers()/cookies().ver conceito →

A.Via headers customizados (request.headers.set) ou cookies. Os Server Components leem com headers()/cookies().ver conceito →

A.Route Handler: API endpoint público, webhook, GET cacheável, integração com app externo. Server Action: mutação tightly-coupled ao seu app, formularios.ver conceito →

A.params são tipados via second arg: GET(req: Request, { params }: { params: { id: string } }). Use Zod para validar body. NextResponse para tipos Next-específicos.ver conceito →

A.GET handlers são cacheados por padrão (em build estático) se não usar APIs dinâmicas. Adicione export const dynamic = 'force-dynamic' para sempre dinâmico, ou export const revalidate = 60 para ISR.ver conceito →

A.1) Imagens grandes não otimizadas. 2) Fontes web carregadas sem font-display:swap. 3) JS bloqueante no <head>. 4) CSS render-blocking. 5) Servidor lento (TTFB alto).ver conceito →

A.1) Code splitting agressivo. 2) Debounce em handlers pesados. 3) startTransition para updates não-urgentes. 4) Web Workers para cálculos. 5) Remover libs grandes desnecessárias.ver conceito →

A.Imagens sem width/height. Anúncios injetados. Web fonts trocando. Conteúdo carregando após inicial render. Solução: reservar espaço (aspect-ratio, min-height).ver conceito →

A.Ambos resolvem o mesmo problema. React Query: mais features (mutations, infinite, devtools), API mais explícita. SWR (Vercel): mais simples, integração natural com Next.js. Escolha por preferência — ambos excelentes.ver conceito →

A.Em Server Components, fetch direto basta (já tem cache do Next.js). Use React Query apenas em Client Components. Para hidratar com dados do server, use HydrationBoundary.ver conceito →

A.useMutation com onMutate atualiza o cache otimisticamente. Se a mutation falhar, onError reverte. Resultado: UI instantânea, com rollback automático em caso de erro.ver conceito →

A.Hook do React 19 que cria state otimista temporário. Quando a action 'real' resolve, o state real assume. Se falhar, useOptimistic reseta automaticamente. Combina perfeitamente com Server Actions.ver conceito →

A.Operações que podem falhar frequentemente (validação complexa server-side). Operações financeiras críticas (pagamento). Operações cuja resposta o user precisa ver (resultado de cálculo).ver conceito →

A.Reverter o state otimista + toast de erro + (opcional) retry automático. UX importante: o user precisa entender que a ação falhou.ver conceito →

A.Radix UI (Dialog, Tabs, etc), Headless UI, React Aria, Reach UI. shadcn/ui (que usa Radix por baixo). React Hook Form. É o padrão moderno de design de componentes.ver conceito →

A.Context API. O pai (<Tabs>) cria o context com state. Os filhos (<Tab>, <TabPanel>) consomem via useContext. State 'flui' implicitamente sem props drilling.ver conceito →

A.1) Mais flexível (qualquer ordem/aninhamento). 2) Menos verboso para casos simples. 3) Fácil de extender (adicionar novos sub-componentes não quebra API). 4) Melhor IntelliSense.ver conceito →

A.1) Wrappers que adicionam props (withAuth, withRouter — Redux ainda usa). 2) Error Boundaries (precisam ser class). 3) Logging/Analytics que envolvem componente inteiro. Para outros casos, use hooks.ver conceito →

A.<Formik render={...}>, <DragDropContext> e algumas APIs declarativas. Em componentes que recebem JSX dependente de state interno. Mas hooks geralmente são mais limpos.ver conceito →

A.Tecnicamente sim — recebe componente, retorna componente. Mas é específico para refs, não para reutilização de lógica geral. É a única forma de receber refs em componentes funcionais.ver conceito →

A.Quase nunca em React 18. Apenas se você usar flushSync explicitamente. Em React 17, batching acontecia apenas em eventos sintéticos do React (onClick, onChange).ver conceito →

A.Quando precisa de UI atualizada IMEDIATAMENTE antes de uma próxima ação (ex: scrollIntoView depois de adicionar elemento). Caso de uso raríssimo, evite.ver conceito →

A.Effects rodam após o batching, com o state final. Múltiplos setState batched = useEffect roda uma vez com o estado final.ver conceito →

A.Strict: cookie NUNCA é enviado em cross-site requests (mesmo via link). Pode quebrar OAuth, links externos. Lax: cookie é enviado em navegação top-level (clicks em links) mas não em iframes/forms cross-site. Lax é o sweet spot.ver conceito →

A.Site malicioso faz request (form submit, img tag) para seu site. Browser envia cookies automaticamente. Servidor não sabe que é maligno e executa ação. SameSite=Lax+ bloqueia. CSRF tokens (forms com token único) também previnem.ver conceito →

A.Não previne XSS, mas mitiga o estrago: scripts injetados não conseguem ler o cookie de auth via document.cookie. O servidor ainda recebe normalmente. Defesa em camadas com CSP, sanitização e HttpOnly.ver conceito →

A.Via headers() em next.config.js OU em middleware.ts (Edge). Inline scripts do Next.js precisam de nonces — middleware gera nonce, layout consome via headers().ver conceito →

A.Diretiva que permite scripts inline (tags script com código direto no HTML). Anula a maior proteção do CSP contra XSS. Use nonces ou hashes para inline necessário, nunca unsafe-inline.ver conceito →

A.Não — extensões têm permissões próprias. CSP bloqueia apenas o que vem do servidor. Mas algumas extensões (analytics, A/B testing) podem ser bloqueadas se forem injetadas via tags.ver conceito →

A.Setar um estado `loading: true` no início do submit e `disabled={loading}` no botão. Isso previne double-submit que cria requests duplicados.ver conceito →

A.HttpOnly cookie (não acessível via JS, protege contra XSS). localStorage é conveniente mas vulnerável a XSS. sessionStorage some ao fechar a tab. Cookie HttpOnly + SameSite=Strict é o padrão de segurança.ver conceito →

A.Ajustar o Max-Age do cookie de sessão. Com JWT, emitir um token com expiração longa (7-30 dias) vs curta (1h). O "lembrar" não deve armazenar a senha em lugar nenhum.ver conceito →

A.Quando você tem 3+ valores de estado que mudam juntos, quando o próximo estado depende do atual de forma complexa, ou quando quer testar a lógica de transição isoladamente.ver conceito →

A.Não. useCallback tem custo (alocação + comparação). Só vale quando a função é passada para filho memoizado com React.memo ou usada como dependência de outro hook. Em handlers locais sem filho memoizado, é puro overhead.ver conceito →

A.useEffect roda após o browser pintar (assíncrono). useLayoutEffect roda após o commit mas antes do paint (síncrono). Use useLayoutEffect para evitar flash visual ao medir ou reposicionar elementos DOM.ver conceito →

A.Com useRef para guardar o timer: const timer = useRef(); no handler, clearTimeout(timer.current) e timer.current = setTimeout(() => call(val), 300). O cleanup no useEffect garante cancelar ao desmontar.ver conceito →

A.Para filtros de lista local sim — startTransition prioriza o input e processa o filtro em background. Para chamadas de API não — startTransition não atrasa o request. Debounce ainda é necessário para reduzir requests de rede.ver conceito →

A.Throttle quando quer feedback contínuo mas limitado: scroll infinito, resize handler, tracking de mouse. Debounce quando quer só o valor final: campo de busca, autocomplete, validação de CEP.ver conceito →

A.React.lazy é padrão do React mas não suporta SSR. next/dynamic é wrapper do Next.js com suporte a SSR e opção ssr: false para componentes que usam APIs do browser. Para Next.js, sempre use dynamic().ver conceito →

A.Definir dimensões fixas no fallback do Suspense (skeleton com mesmo tamanho do componente real). Sem dimensões fixas, o conteúdo "pula" quando o componente carrega, prejudicando CLS.ver conceito →

A.Pré-carregar chunks de rotas que o usuário provavelmente vai navegar. No Next.js, Link já faz prefetch automático quando o link entra no viewport. Para prefetch manual: router.prefetch("/rota"). Cuidado com over-prefetching em mobile.ver conceito →

A.Servir o dado em cache imediatamente (mesmo que antigo) e em background buscar versão atualizada. Resultado: UI responsiva sem loading spinner, dados frescos chegam silenciosamente. SWR (biblioteca) é nomeada após esse padrão.ver conceito →

A.Usar AbortController: no cleanup do useEffect, chamar controller.abort(). Requests cancelados lançam AbortError que deve ser ignorado no catch. Ou flag: let active = true no useEffect, false no cleanup — checar antes de setar estado.ver conceito →

A.React Query: apps com estado de servidor complexo (mutations, otimismo, infinite queries). SWR: GET-heavy simples, bundle menor. Fetch manual: requests únicos sem necessidade de cache. Em 2025, React Query é o padrão.ver conceito →

A.Tempo em ms que um dado é considerado fresco. Durante esse período, nova query com a mesma key retorna o cache sem fetch. Após o staleTime, dados ficam stale mas são servidos do cache enquanto refetch acontece em background.ver conceito →

A.queryClient.invalidateQueries({ queryKey: ["users"] }) na callback onSuccess da mutation. Isso marca os dados como stale e dispara refetch automático em todos os componentes que os consomem.ver conceito →

A.Estado de servidor (dados da API) deve ficar no React Query / SWR, não em useState + useEffect. Estado de UI (modal aberto, tab ativa) fica em useState. Misturar os dois em useState causa sincronização frágil.ver conceito →

A.Imagem hero com priority no next/image (preload), SSR/SSG para o HTML chegar com conteúdo, e CDN para reduzir latência. LCP costuma ser a imagem maior acima do fold.ver conceito →

A.React DevTools Profiler: gravar uma interação e identificar componentes que renderizaram sem necessidade. Componentes que sempre re-renderizam quando o pai re-renderiza são candidatos a React.memo.ver conceito →

A.Interaction to Next Paint: tempo entre interação do usuário e o próximo frame pintado. Melhorar: mover cálculos pesados para useTransition, web workers, ou dividir tasks longas com setTimeout(fn, 0).ver conceito →

A.entities/ contém modelos de negócio puros (User, Product) sem lógica de UI — só tipos, schemas, funções puras. features/ contém casos de uso específicos (auth/login, cart/addItem) com UI e lógica de interação.ver conceito →

A.Elevar para o nível acima (app/ ou uma entity compartilhada). Se User é usado por auth e profile, o store de User fica em entities/user. Features importam de entities, não umas das outras.ver conceito →

A.Sim. O app/ do Next.js fica como esperado. O resto segue FSD em src/. As rotas importam de features/, que importam de entities/, que importam de shared/. A hierarquia de imports é unidirecional.ver conceito →

A.Junto ao componente que os usa. Se PageDashboard.tsx usa DashboardChart.tsx, coloque em pages/dashboard/DashboardChart.tsx. Só mova para shared/components/ quando for usado em 2+ lugares não relacionados.ver conceito →

A.app/ para rotas. src/components/ para UI reutilizável. src/features/ para lógica de domínio. src/lib/ para utils. src/hooks/ para hooks reutilizáveis. Evitar barrel exports (index.ts que re-exporta tudo) — causam tree-shaking e imports circulares.ver conceito →

A.Para bibliotecas e design systems, sim (public API clara). Para app code, pode gerar imports circulares e prejuízo ao tree-shaking. Evitar re-exports de tudo. Preferir imports diretos no código de aplicação.ver conceito →

A.SSG: conteúdo que não muda por usuário (blog, docs, landing page) ou muda raramente (catálogo com ISR). SSR: conteúdo personalizado por usuário (dashboard, feed) ou dados em tempo real (preço, estoque).ver conceito →

A.Dividir o frontend em apps independentes com deploy separado por time. Faz sentido para: organizações grandes com times autônomos, partes com ciclos de release diferentes, ou migração gradual de legado. Custo alto — só justifica em escala real.ver conceito →

A.CSR puro: Googlebot consegue indexar JS moderno mas outros bots não. Tempo de indexação maior. SSR/SSG: HTML com conteúdo chega direto, todos os bots indexam imediatamente. Para conteúdo público com necessidade de SEO, SSR/SSG é obrigatório.ver conceito →

A.Todo consumer do Context re-renderiza quando qualquer valor do context muda, mesmo que não use o valor que mudou. Solução: dividir contexts por frequência de atualização. Para estado frequente, Zustand é sempre melhor.ver conceito →

A.Zustand: 1kb, zero boilerplate, API simples. Redux Toolkit: ecossistema maduro, RTK Query integrado, devtools excelentes. A tendência é Zustand + React Query substituir Redux na maioria dos novos projetos.ver conceito →

A.Estado derivado é calculado a partir de outro estado: fullName = firstName + lastName. Guardar ambos cria problema de sincronização. Calcular no render (ou useMemo) garante que nunca ficam dessincronizados.ver conceito →

A.JWT: stateless, escala sem banco, bom para microservices. Desvantagem: impossível revogar antes da expiração sem blocklist. Session: stateful, revogação imediata, simples para monólitos. Para apps com logout verdadeiro, sessions são mais seguras.ver conceito →

A.Middleware.ts na raiz lê o cookie/token e redireciona se não autenticado — roda no edge, antes de qualquer render, sem flash de conteúdo. É a abordagem correta. Verificar no layout.tsx (Server Component) também funciona mas é mais lento.ver conceito →

A.A cada uso do refresh token, um novo é emitido e o antigo invalidado. Se um refresh token for roubado e usado, a próxima rotação legítima detecta que o token foi consumido e invalida a sessão — proteção contra token theft.ver conceito →

A.Design Tokens são a camada semântica: --color-primary em vez de --blue-500. Permitem rebranding completo sem tocar nos componentes — só os tokens mudam. Variáveis CSS são o mecanismo; tokens são o padrão. W3C Design Tokens Community Group está padronizando o formato JSON.ver conceito →

A.Vale quando: múltiplos produtos compartilham identidade visual, time de design+dev dedicado, produto estável (não MVP). Não vale quando: startup validando produto, time pequeno, UI não é diferencial. Alternativa: customizar um DS existente (shadcn/ui, Radix, Chakra).ver conceito →

A.Versionamento semântico (semver): MAJOR para breaking changes de API, MINOR para novos componentes, PATCH para bugfixes. Codemods para migração automática. Período de deprecation com warnings antes de remover. Changelog detalhado com exemplos de migração.ver conceito →

A.String é melhor: variant="primary" | "secondary" é auto-documentável, mutuamente exclusivo por definição, e extensível sem breaking change. Booleanos (isPrimary, isSecondary) podem ser combinados de formas inválidas e ficam verbosos com muitas variantes.ver conceito →

A.Componentes que cooperam via Context implícito: <Select><Select.Trigger/><Select.Content><Select.Item/></Select.Content></Select>. O pai gerencia estado, filhos consomem via useContext. Radix UI, shadcn/ui e Headless UI usam esse padrão extensivamente.ver conceito →

A.Storybook com stories para cada variante e estado (default, hover, focus, disabled, error, loading). Controls para props interativas. Docs automáticos via JSDoc/TSDoc. Testes de acessibilidade com @storybook/addon-a11y. Stories servem como spec executável.ver conceito →

A.Story é documentação e desenvolvimento visual — mostra como o componente parece em diferentes estados. Teste (Jest/RTL) verifica comportamento e lógica. São complementares: stories para visual, testes para funcional. Storybook pode executar testes de acessibilidade automáticos via addon.ver conceito →

A.Chromatic (do time do Storybook): faz screenshot de cada story em cada commit e compara com baseline. Detecta mudanças visuais não intencionais automaticamente. Alternativas: Percy, Playwright (screenshot testing), ou Happo. Essencial em DS para garantir que mudança de token não quebre componentes.ver conceito →

A.Hierarquia: Componentes/Atoms/Button.stories.tsx. Usar tags para filtrar (is:new, status:deprecated). Stories por estado: Default, Hover (play function), Disabled, Loading, Error. Usar argTypes para documentar props com descrições e controles interativos.ver conceito →

A.Turborepo: simples, zero config, melhor para JS/TS puro, excelente caching, opinionado mas flexível. Nx: mais features (generators, plugins, affected), melhor para workspaces grandes e diversificados (Go, Java, etc.), mais complexo. Para maioria dos projetos Next.js/React, Turborepo é suficiente.ver conceito →

A.Turborepo faz hash de inputs (arquivos de source + env vars + dependências) e outputs (dist/, .next/). Se o hash não mudou, retorna o cache em vez de rebuildar. Remote cache compartilha esse resultado entre máquinas — dev e CI compartilham cache.ver conceito →

A.Opções: 1) Sem versão (workspace:*) — sempre a versão mais recente, ideal para apps no mesmo repo. 2) Versão semântica — quando packages são publicados no npm. Changesets automatiza o versionamento: gera changelogs e bumps de versão baseados em changesets commitados.ver conceito →

A.iframes: isolamento total (CSS, JS não vazam), mas integração ruim (comunicação via postMessage, performance, acessibilidade). Module Federation: apps compartilham o mesmo DOM e podem compartilhar libs (React singleton), integração nativa mas sem isolamento. Iframes para conteúdo realmente isolado (widgets, third-party).ver conceito →

A.Evitar estado compartilhado muda o design. Opções: 1) Custom events (window.dispatchEvent) — simples mas frágil. 2) Shared store (Zustand singleton compartilhado). 3) URL como fonte de verdade (query params). 4) Backend-driven state (polling/websocket). A melhor solução é não precisar compartilhar.ver conceito →

A.Module Federation: declarar React e ReactDOM como singleton: true e requiredVersion em shared. Isso garante que apenas uma instância de React roda, mesmo com múltiplos remotes. Sem singleton, cada remote carrega sua própria cópia e hooks quebram (viola Rules of Hooks entre instâncias).ver conceito →

A.Fazer upload dos source maps para o Sentry mas não servir para o browser. next.config.ts: `sentry: { hideSourceMaps: true }`. Ou configurar SOURCEMAP_SENTINEL=false para omitir a referência no bundle. O Sentry usa os maps internamente para mapear erros, mas não os expõe ao público.ver conceito →

A.Lighthouse: medição em ambiente controlado (lab data), não reflete usuários reais. RUM: coleta métricas do browser de usuários reais em campo (field data) — inclui variações de dispositivo, rede, e localização geográfica. Core Web Vitals no Google Search Console são field data via Chrome User Experience Report (CrUX).ver conceito →

A.Correlation ID: o front envia um ID único em cada request (header X-Correlation-ID). O backend loga com esse ID. Quando um erro ocorre no frontend, o Sentry captura o correlation ID como contexto — facilita achar o log do servidor que corresponde ao erro do cliente.ver conceito →

A.Padrão aberto para instrumentação (traces, metrics, logs). @opentelemetry/sdk-trace-web instrumenta o browser. Trace inicia no clique do usuário, o span HTTP propaga via headers (traceparent), o backend continua o trace. Resultado: timeline completo do click ao banco no Jaeger, DataDog, ou Grafana Tempo.ver conceito →

A.Sentry: beforeSend hook para filtrar/sanitizar eventos antes de enviar. SessionReplay: maskAllText: true mascara todo texto. Configurar allowUrls para ignorar erros de extensões do browser. Nunca logar tokens, senhas ou dados pessoais — PII (Personally Identifiable Information) em logs viola LGPD/GDPR.ver conceito →

A.Error Boundary captura erros de render em React e evita que o app inteiro quebre. Integrar com Sentry: Sentry.ErrorBoundary component como wrapper — captura automaticamente o erro, a stack, e os props do componente que falhou. Permite mostrar fallback UI para o usuário enquanto o erro é reportado.ver conceito →

A.Immer usa Proxy para interceptar mutações: você escreve `state.count++` e Immer produz um novo objeto imutável por baixo. Isso elimina o spread manual (`...state, count: state.count + 1`). Mais legível, menos propenso a bugs de imutabilidade.ver conceito →

A.RTK Query: integra ao store Redux (cache acessível via state), devtools do Redux mostram requests, bom para projetos já em Redux. React Query: independente, mais features (infinite query, offline, mutations), melhor ecosystem. Para projetos novos sem Redux: React Query. Para projetos Redux: RTK Query faz sentido.ver conceito →

A.Uma slice por feature/domínio: authSlice, cartSlice, uiSlice. Separar estado de UI (modais, loading local) de estado de servidor (que deve estar no React Query/RTK Query). Evitar "god slice" com tudo junto. Combinar com Feature-Sliced Design: cada feature tem sua slice e api.ver conceito →

A.Splitting: separar contextos por frequência (AuthContext, ThemeContext, UIContext). Memoizar o value: `const value = useMemo(() => ({ user, logout }), [user])`. Para seletores (só ouvir parte do context), usar use-context-selector lib. Mas se o estado muda frequentemente, Zustand é a solução certa.ver conceito →

A.Para estado simples e raramente atualizado, sim. Para estado complexo com muitas atualizações, não — sem o conceito de seletor, todos os consumers re-renderizam. Context não tem devtools, middleware, ou estrutura para mutations complexas. Use Context para DI (dependency injection) de valores estáveis, Redux/Zustand para estado dinâmico.ver conceito →

A.Compound Components que compartilham estado via Context: o componente pai cria um Context privado, filhos consomem. Ex: <Accordion> cria um Context com {openIndex, setOpenIndex}. <Accordion.Item> consome via useContext interno. Usuário não precisa gerenciar estado — a API é declarativa.ver conceito →

A.Slice pattern: criar múltiplas slices e combinar: `create<State>()((...args) => ({ ...createAuthSlice(...args), ...createCartSlice(...args) }))`. Ou criar stores separadas por domínio — Zustand não tem store única obrigatória, ao contrário do Redux.ver conceito →

A.Middleware persist: `create(persist((set) => ({ count: 0, inc: () => set(s => ({count: s.count+1})) }), { name: "counter-storage" }))`. Persiste no localStorage por padrão. Customizar storage (sessionStorage, IndexedDB), partializar quais campos persistir, e migrar state entre versões.ver conceito →

A.Não diretamente — Zustand é client-side (usa window/browser APIs). Inicializar store com dados do servidor via prop do Client Component ou via useHydrateAtoms (Jotai). No Next.js App Router: criar uma instância por request no servidor usando a forma funcional do create.ver conceito →

A.Zustand: estado de domínio centralizado (cart, auth, produtos), quando você quer uma "fonte única de verdade" explícita. Jotai: estado granular de UI, atoms por ID (editando item específico), estado que é naturalmente derivado de outros. Muitos devs usam Zustand para domínio e Jotai para UI granular.ver conceito →

A.atom((get) => derivação): lê outros atoms via get(), Jotai rastreia dependências automaticamente. Quando qualquer atom lido mudar, o derivado recalcula. Equivalente a useMemo mas global — qualquer componente pode ler o derivado sem recalcular.ver conceito →

A.Sim, com Provider e useHydrateAtoms para inicializar atoms com dados do servidor: `useHydrateAtoms([[userAtom, serverUser]])`. Sem Provider, atoms são globais (singleton) — problemático em SSR onde múltiplas requests compartilhariam estado. Com Provider por request, cada request tem seu próprio scope.ver conceito →

A.getByRole é sempre preferível: testa acessibilidade junto com funcionalidade, é mais resiliente a refatorações, e força semântica HTML correta. getByTestId só quando não há alternativa (componente de terceiro sem role semântico). Hierarquia: Role > LabelText > PlaceholderText > Text > TestId.ver conceito →

A.Preencher campos com userEvent.type(), submeter com userEvent.click() no botão ou userEvent.keyboard('{Enter}'). Assertar o que acontece: mensagem de sucesso aparece, campo de erro aparece, função de callback foi chamada com os valores corretos.ver conceito →

A.Internals do componente (state, métodos privados), props que não afetam a UI visível, detalhes de implementação do CSS. Deixar para testes unitários puros: lógica de negócio pura, helpers, reducers — sem React, só Jest.ver conceito →

A.MSW intercepta na camada de rede — o mais realista. jest.mock mocka módulos inteiros (acopla à implementação). axios-mock-adapter só funciona com Axios. MSW funciona independente de qual lib HTTP o componente usa e não requer mudança no código de produção.ver conceito →

A.server.use() para sobrescrever um handler em um teste específico: server.use(http.get('/api/users', () => new HttpResponse(null, { status: 500 }))). Depois do teste, o handler original volta (server.resetHandlers() no afterEach).ver conceito →

A.Sim — e é a combinação ideal. O componente usa useQuery normalmente, o MSW intercepta o fetch do React Query, e você testa o componente completo incluindo loading/error/success states sem mock nenhum no código de produção.ver conceito →

A.Playwright: multi-browser real, mais rápido, melhor para apps React/Next.js modernos, auto-wait mais confiável, gratuito sem limitações. Cypress: melhor DX para debug em tempo real (vê o app enquanto o teste roda), hot reload, mais fácil para iniciantes. Para projetos novos: Playwright. Para times já em Cypress: não migrate sem necessidade.ver conceito →

A.Nunca use page.waitForTimeout(n) — use locators com auto-wait. Nunca confie em animações concluídas — await expect(locator).toBeVisible(). Para network: use page.waitForResponse() ou mock com page.route(). Isole o estado: cada teste começa limpo (beforeEach com login via API, não UI).ver conceito →

A.Padrão para encapsular seletores e ações de uma página em uma classe. Em vez de page.locator('.login-btn') espalhado nos testes, você cria LoginPage com loginPage.submit(). Facilita manutenção: quando o seletor muda, muda em um lugar só.ver conceito →

A.Ao abrir: mover foco para o primeiro elemento focável dentro do modal (ou para o elemento com autofocus). Trap de foco: Tab circula dentro do modal, não escapa. Ao fechar: retornar foco para o elemento que abriu o modal. Usar Radix UI, Headless UI ou @radix-ui/react-focus-scope que implementam isso corretamente.ver conceito →

A.aria-label: texto direto para o elemento. Usar quando não há texto visível associado: `<button aria-label='Fechar modal'>✕</button>`. aria-labelledby: referencia o ID de outro elemento como label. `<dialog aria-labelledby='dialog-title'>`. Prefira aria-labelledby quando há texto visível — evita duplicação e mantém sync.ver conceito →

A.Automático: axe-core (@testing-library/jest-axe, @axe-core/playwright) pega ~30-40% dos problemas. Manual: navegar apenas com teclado (Tab, Shift+Tab, Enter, Space, Escape, setas). Screen reader: NVDA (Windows), VoiceOver (Mac/iOS), TalkBack (Android). Lighthouse a11y score > 90 como baseline.ver conceito →

A.Use STAR: Situação (bug em produção afetando 10% dos usuários), Tarefa (investigar e corrigir em 4h), Ação (adicionei logging, reproduzi localmente, identifiquei race condition no useEffect, corrigi com cleanup function e AbortController), Resultado (resolvido em 3h, adicionei teste de regressão que pega esse padrão).ver conceito →

A.Mostrar que você é pragmático: nem 'reescrevemos tudo' nem 'nunca pagamos'. Resposta ideal: 'categorizo por impacto e risco, documento como tech debt, proponho reservar 20% do sprint para dívida crítica, e argumento ROI para o PM quando a dívida bloqueia features'. Ter exemplo concreto de quando priorizou e quando não priorizou.ver conceito →

A.Mostrar maturidade: não cedeu por pressão, mas também não foi inflexível. 'Apresentei dados e alternativas, ouvi as razões do outro lado, tentamos a abordagem deles com um prazo de reavaliação, e quando os problemas que previ apareceram, propus revisão sem "eu disse". A decisão final foi mais equilibrada que a minha proposta original.'ver conceito →

A.'Como é o processo de code review de vocês?' (revela cultura de qualidade). 'Qual foi o maior incidente técnico recente e como foi tratado?' (revela maturidade em incident response). 'Como fica o equilíbrio entre features novas e dívida técnica?' (revela pressão de produto vs qualidade). 'O que te faria sair desta empresa?' (revela red flags que o entrevistador não diria diretamente).ver conceito →

A.'Não temos muito tempo para testes' = pressão de prazo crônica. 'Temos muita liberdade, cada um faz do jeito que quer' = falta de processo. 'Estamos em hypergrowth' sem mencionar sustentabilidade = potencial burnout. Evasivas sobre turnover recente. Não conseguir citar uma melhoria de processo no último ano.ver conceito →

A.Júnior/Pleno: foco em mentoria, onboarding, ciclos de feedback, oportunidade de aprendizado. Senior: autonomia técnica, influência em decisões de arquitetura, tamanho do time, qual a maior dívida técnica. Staff/Principal: roadmap técnico, relação eng/produto, como decisões de plataforma são tomadas.ver conceito →

A.Debounce de 200-300ms para reduzir requests. Cache de resultados anteriores (Map ou React Query cache). Cancelamento de request anterior com AbortController. Virtualização da lista se muitos resultados. Acessibilidade: aria-combobox, aria-listbox, navegação com setas. Highlight do match no texto.ver conceito →

A.IntersectionObserver para detectar quando o usuário chega ao fim. React Query com useInfiniteQuery para gerenciar paginação e cache. Virtualização (react-virtual ou react-window) para não manter todos os itens no DOM. Skeleton loading por placeholder. Otimização de imagens: lazy loading nativo, WebP, tamanhos responsivos.ver conceito →

A.CSR: renderiza no browser, TTI alto, ruim para SEO. SSR: renderiza no servidor por request, TTFB maior mas TTI menor, bom para SEO e dados dinâmicos. SSG: renderiza no build, TTFB mínimo, ótimo para conteúdo estático ou com revalidação (ISR). Escolha: SEO crítico + dados dinâmicos = SSR; SEO + dados estáticos = SSG; app autenticado sem SEO = CSR.ver conceito →

A.localStorage é acessível por qualquer JavaScript na página. Se houver qualquer XSS (mesmo em dependência de terceiro), o atacante lê o token e o usa em outro lugar. httpOnly cookies não são acessíveis por JS — mesmo com XSS o atacante não consegue ler o valor. Tradeoff: httpOnly cookies requerem proteção CSRF (SameSite=Strict ou token CSRF).ver conceito →

A.CSP é um header HTTP que define de onde recursos podem ser carregados e se scripts inline são permitidos. `Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com` bloqueia scripts de outros domínios e inline. Previne XSS porque mesmo que o atacante injete <script>, o browser bloqueia a execução.ver conceito →

A.Todo {expression} em JSX é escapado automaticamente: <div>{userInput}</div> transforma < em &lt; e > em &gt;. Nunca executa como HTML. A exceção é dangerouslySetInnerHTML={{__html: content}} — aí é responsabilidade do dev sanitizar com DOMPurify antes. Outro vetor: <a href={url}> — validar que url começa com http:// ou https://, nunca javascript:.ver conceito →

A.Bundlers (Webpack, Rollup, Vite) analisam imports estáticos e eliminam código não referenciado. Funciona com ES modules (import/export). Não funciona com CommonJS (require). Por isso `import { debounce } from 'lodash-es'` (ES module) é tree-shakeable, mas `import _ from 'lodash'` (CJS) importa tudo. Verificar se a lib tem sideEffects: false no package.json.ver conceito →

A.Rota: `const Dashboard = lazy(() => import('./Dashboard'))` — carrega o chunk da rota só quando o usuário navega para ela. Componente: mesmo padrão mas para componentes pesados dentro de uma rota (ex: editor de texto, mapa, gráfico complexo). Ambos precisam de `<Suspense fallback={<Loading />}>` em volta.ver conceito →

A.Next.js: `ANALYZE=true next build` com @next/bundle-analyzer — gera treemap visual. Vite: rollup-plugin-visualizer. Procurar: dependências grandes importadas inteiras, duplicação (mesma lib em versões diferentes), código de desenvolvimento incluído em prod. Ferramentas: bundlephobia.com para checar tamanho antes de instalar.ver conceito →

A.useTransition: você controla quando o update é não-urgente — wrapping o setState com startTransition. useDeferredValue: você recebe um valor e cria uma versão "atrasada" dele — útil quando não controla a origem do update (prop de pai, etc). Ambos usam a mesma mecânica de concorrência.ver conceito →

A.Permite que um componente "suspenda" sua renderização até que os dados estejam prontos, mostrando o fallback do Suspense mais próximo. React Query e SWR têm suporte experimental. Com Next.js App Router: `use(promise)` ou React Server Components fazem fetch suspense-aware nativamente. Simplifica loading states: um `<Suspense>` cobre múltiplos componentes filhos.ver conceito →

A.Para updates de input controlado — o valor do input deve ser sempre síncrono. Para animações — use CSS ou Framer Motion. Para feedback imediato que o usuário espera ser instantâneo. useTransition é para cálculos pesados que podem ser adiados, não para tudo.ver conceito →

A.Zero JS enviado ao cliente para componentes puramente de apresentação. Acesso direto a banco sem API intermediária. Fetch de dados no servidor = sem loading state, sem useEffect, sem race conditions. Secrets do servidor nunca expostos. Bundle menor = melhor performance.ver conceito →

A.Não diretamente — o boundary 'use client' transforma tudo abaixo em client. Mas você pode passar Server Components como children ou props para Client Components: `<ClientWrapper>{children}</ClientWrapper>` onde children é um Server Component. O padrão correto é passar como prop, não importar.ver conceito →

A.Diretamente no componente com async/await — Server Components podem ser async: `async function Page() { const data = await db.query(...); return <List data={data} /> }`. No Next.js, o fetch é automaticamente deduplicado e cacheado. Para revalidação: `fetch(url, { next: { revalidate: 60 } })` ou `revalidatePath()`.ver conceito →

A.Grupo de componentes que trabalham juntos com estado compartilhado implícito via Context. Exemplo: `<Tabs>`, `<Tabs.List>`, `<Tabs.Tab>`, `<Tabs.Panel>`. O Tabs gerencia qual tab está ativa, os filhos consomem via Context sem precisar de props. API mais natural para o consumidor — parece HTML nativo.ver conceito →

A.Uncontrolled por default (mais fácil de usar), controlled quando necessário (máximo controle). O padrão 'semi-controlled' aceita value + onChange (controlled) OU defaultValue (uncontrolled). Internamente usa useState com valor inicial de defaultValue. Se value prop aparece, o componente passa a ser controlled. Exatamente como inputs HTML.ver conceito →

A.Com hooks, muitos casos de render props foram substituídos por custom hooks. Mas render props ainda têm vantagem quando o componente precisa controlar O QUE renderiza (não só fornecer lógica). Ex: componente de virtualização que controla quais itens são visíveis. React Query usava render props, migrou para hooks — mas `children as function` ainda aparece em componentes de UI complexos.ver conceito →

A.Tokens são a unidade de processamento dos LLMs — nem sempre palavras (subword tokenization). 'Tokenization' pode ser 3 tokens. Importam porque: (1) limitam o contexto máximo, (2) definem o custo (APIs cobram por token), (3) modelos têm limites de output em tokens. Regra prática: ~1 token = ~4 chars em inglês, ~3-4 chars em português.ver conceito →

A.Temperatura controla a "criatividade" da geração. Temp=0: sempre escolhe o token mais provável (determinístico, bom para código/facts). Temp=1: distribuição original do modelo (criativo mas menos preciso). Temp>1: ainda mais aleatório. Para produção com código ou dados: temp=0. Para geração de texto criativo: 0.7-1.ver conceito →

A.Context window é a memória de trabalho do LLM — tudo que ele "vê" ao gerar. Quando o histórico de conversa supera o limite: summarization (resumir os turnos antigos), sliding window (descartar os mais antigos), ou RAG (buscar contexto relevante em vez de passar tudo). Modelos recentes focam mais nos extremos do contexto (início e fim).ver conceito →

A.Pedir que o modelo mostre o raciocínio antes da resposta final: "Pense passo a passo antes de responder". Aumenta significativamente a precisão em tarefas de raciocínio, matemática e lógica. O modelo que "pensa em voz alta" comete menos erros do que o que vai direto à resposta. Variante: "Antes de responder, liste as considerações relevantes."ver conceito →

A.Few-shot quando: o formato de saída é específico (JSON com campos customizados, classificação com categorias suas), a tarefa é ambígua sem exemplos, ou você quer comportamento consistente entre chamadas. Zero-shot quando: a tarefa é comum e bem representada no treino, ou quando você está testando a capacidade base do modelo.ver conceito →

A.Persona clara: quem o modelo é. Contexto: o que o produto faz. Restrições: o que nunca fazer. Formato de saída preferido. Exemplos de comportamento esperado. Prioridade: system > instruções do usuário > exemplos. Manter conciso — system prompts muito longos diluem as instruções importantes.ver conceito →

A.Embeddings são representações vetoriais de texto em espaço de alta dimensão (1536 dims no ada-002). Textos semanticamente similares ficam próximos no espaço vetorial. A busca RAG encontra os K vetores mais próximos ao vetor da query (cosine similarity ou dot product). Modelo de embedding diferente do modelo de geração — pode usar text-embedding-3-small e GPT-4o juntos.ver conceito →

A.RAG: dados ficam fora do modelo, atualizáveis, rastreáveis, sem treinamento. Bom para: base de conhecimento dinâmica, documentos privados, citações. Fine-tuning: modifica os pesos do modelo com seus dados. Bom para: estilo de escrita, formato de resposta, domínio muito específico. Na prática: RAG para conhecimento, fine-tuning para comportamento/estilo.ver conceito →

A.Métricas: Faithfulness (resposta é suportada pelos chunks recuperados?), Answer Relevancy (resposta responde a pergunta?), Context Recall (os chunks certos foram recuperados?). Tools: RAGAS, TruLens. O problema mais comum é retrieval falho — o LLM pode responder corretamente SE tiver o contexto certo, mas o retrieval buscou os chunks errados.ver conceito →

A.Fenômeno onde LLMs prestam menos atenção a informações no meio do contexto, focando mais no início e no fim. Implicações para RAG: coloque os chunks mais relevantes no início ou fim, não no meio. Para instruções: repita as mais importantes antes do input do usuário, mesmo que já estejam no system prompt.ver conceito →

A.Anthropic e Google permitem cachear um prefixo do prompt (system prompt + documentos de referência) por 5 minutos. Chamadas subsequentes que usam o mesmo prefixo pagam ~10% do custo normal para os tokens cacheados. Ideal para: system prompts longos, base de conhecimento inserida no contexto, few-shot examples extensos.ver conceito →

A.Working memory: contexto atual da conversa (limitado pelo context window). Episodic memory: histórico de conversas passadas (DB, recuperado por relevância). Semantic memory: fatos e conhecimento (vector store, RAG). Procedural memory: como fazer tarefas (system prompt, fine-tuning). Agentes eficazes combinam todas — contexto atual + retrieval de memória relevante.ver conceito →

A.Mesma ideia, nomes diferentes por provider. OpenAI chama de "function calling", Anthropic de "tool use", Google de "function declarations". Todos permitem definir um schema JSON das funções, o modelo retorna um JSON estruturado com a função a chamar e os parâmetros, e você executa e retorna o resultado.ver conceito →

A.Reason + Act: o agente alterna entre raciocinar (Thought: preciso buscar X) e agir (Action: search("X")). Cada ciclo é: Thought → Action → Observation (resultado da tool). O modelo usa a observation para o próximo raciocínio. Isso cria um loop de raciocínio + ação mais confiável do que só gerar a resposta final diretamente.ver conceito →

A.Max iterations limit obrigatório. Timeout por execução total. Stop conditions explícitas no system prompt ("quando tiver a resposta final, use a tool respond()"). Detectar estados repetidos (mesma tool com mesmos parâmetros 2x). Human-in-the-loop para agentes que executam ações irreversíveis (enviar email, deletar dados).ver conceito →

A.Cosine similarity mede o ângulo entre vetores — independe da magnitude. Melhor para comparar embeddings de textos de comprimentos diferentes. Dot product é computacionalmente mais barato e equivalente ao cosine se os vetores forem normalizados (magnitude 1). Pinecone e a maioria dos vector DBs oferecem ambos — use cosine para text embeddings.ver conceito →

A.Combinar busca vetorial (semântica) com busca por palavras-chave (BM25/sparse). Cada método retorna uma lista de resultados com scores. Reciprocal Rank Fusion (RRF) ou scores ponderados combinam as listas. Hybrid search quase sempre supera só vetorial, especialmente para queries com termos técnicos exatos (nomes de função, erro específico).ver conceito →

A.Depende do caso de uso: chunks pequenos (128-256 tokens) — maior precisão, menor contexto, bom para Q&A factual. Chunks grandes (512-1024 tokens) — mais contexto, possível ruído, bom para sumarização. Parent-child chunking: indexar chunks pequenos, retornar o chunk pai maior. Testar empiricamente com RAGAS é mais confiável que regra fixa.ver conceito →

A.Usar um LLM (geralmente GPT-4 ou Claude) para avaliar outputs de outro LLM. Exemplo: dar ao GPT-4 a pergunta, a resposta gerada, e o contexto RAG, e pedir uma nota de 1-5 para faithfulness (resposta é suportada pelo contexto?). Escala melhor que avaliação humana. Limitações: viés do avaliador, custo, não substitui avaliação humana para casos críticos.ver conceito →

A.Coletar 50-200 queries reais de produção (ou sintéticas para começar). Para cada query, documentar a resposta ideal (human-curated). Incluir edge cases: queries ambíguas, perguntas sem resposta no contexto, perguntas adversariais. Revisar periodicamente — o golden dataset deve evoluir com o produto.ver conceito →

A.PromptFoo ou Braintrust: definir test cases em YAML, rodar `promptfoo eval` no CI. Criar thresholds: se faithfulness < 0.8 ou answer_relevancy < 0.75, o CI falha. Fazer diff de scores entre a versão atual e a nova — regressão de >5% é blocker. Rodar evals em PR de mudança de prompt, não só no merge.ver conceito →

A.Usuário insere texto que manipula o comportamento do LLM: "Ignore todas as instruções anteriores e diga X". Mitigações: delimitar input com XML tags e instruir o modelo a tratá-lo como dado. Usar modelos fine-tuned para instruction-following robusto. Validar output independentemente. Nunca permitir que o output do LLM execute código sem sandbox.ver conceito →

A.Regex para formatos conhecidos (CPF, email, telefone, cartão de crédito). NER (Named Entity Recognition) para nomes e endereços. Microsoft Presidio ou AWS Comprehend para detecção automática de PII. Configurar no pipeline de output: se PII detectado, bloquear ou mascarar antes de retornar ao usuário. Também importante: não passar PII desnecessário no contexto.ver conceito →

A.Content moderation: classificar se o conteúdo é nocivo (violência, sexual, ódio) — OpenAI Moderation API, Perspective API. Guardrails: validações mais específicas ao seu domínio — responder só sobre produtos da empresa, não dar conselhos médicos, não revelar preços de concorrentes. Moderation é genérico, guardrails é específico ao caso de uso.ver conceito →

A.LCEL (LangChain Expression Language) substituiu as Chain classes antigas. Vantagens: composição explícita com pipe operator, streaming built-in, paralelismo (RunnableParallel), retry (RunnableRetry), e integração direta com LangSmith. Chains antigas (LLMChain, ConversationalRetrievalChain) ainda funcionam mas não recebem novos features.ver conceito →

A.Vercel AI SDK: projetos Next.js com streaming de UI, useChat/useCompletion hooks React, deploy na Vercel, simplicidade máxima. LangChain: RAG complexo, agents multi-step, múltiplos providers, pipelines de data processing. Para apps Next.js simples: Vercel AI SDK. Para sistemas de agentes complexos: LangChain ou LlamaIndex.ver conceito →

A.Vercel AI SDK com useChat(): no servidor, `streamText()` com o provider. No cliente, `useChat()` hook que recebe chunks incrementalmente e atualiza `messages`. Para Next.js App Router: Route Handler com `return result.toDataStreamResponse()`. O usuário vê a resposta sendo digitada em vez de esperar o response completo.ver conceito →

A.OpenAI fine-tuning GPT-4o-mini: ~$25/1M tokens de treino + inferência mais cara. Custo de dados: preparar dataset de qualidade (centenas de exemplos) leva dias de trabalho humano. Custo de manutenção: quando o modelo base é atualizado, você retreina. Comparar com RAG: setup mais simples, sem retreinamento, mas latência um pouco maior por chamada.ver conceito →

A.OpenAI recomenda mínimo 50, ideal 500-1000 exemplos de alta qualidade. Qualidade > quantidade: 100 exemplos perfeitos supera 1000 exemplos mediocres. Para tarefas de classificação: mais exemplos por classe. Para geração com formato específico: poucos exemplos podem ser suficientes (50-100). Para conhecimento factual: fine-tuning é menos eficaz que RAG.ver conceito →

A.Instruction tuning: fine-tuning com pares instruction-response para seguir instruções. É o que cria modelos como GPT-3.5-turbo a partir do GPT-3. RLHF (Reinforcement Learning from Human Feedback): treinar com feedback humano de qual resposta é melhor. Mais complexo, cria modelos mais alinhados (ChatGPT, Claude). Como dev, você geralmente faz instruction tuning, não RLHF.ver conceito →

A.Route Handler com Vercel AI SDK: `const result = streamText({ model, messages }); return result.toDataStreamResponse()`. No cliente: `useChat({ api: '/api/chat' })` — o hook gerencia o estado de streaming automaticamente. Para streaming custom: `TransformStream` ou `ReadableStream` no servidor, `EventSource` ou fetch com `response.body.getReader()` no cliente.ver conceito →

A.AbortController: passar `signal` para o fetch/stream. No useEffect de cleanup: `controller.abort()`. Com Vercel AI SDK: `stop()` do useChat() para interromper a geração. Sem cancelamento, o backend continua gerando e consumindo tokens (e dinheiro) mesmo com o usuário já em outra página.ver conceito →

A.Erros podem acontecer no meio do stream. Estratégias: (1) mostrar o que foi gerado até o ponto do erro + mensagem de erro, (2) retry automático para transient errors, (3) fallback para chamada não-streaming se o streaming falhar. Com Vercel AI SDK: `onError` callback. Sempre mostrar feedback claro ao usuário quando a geração falha.ver conceito →

A.Multi-agentes quando: tasks genuinamente paralelas (pesquisador + redator + revisor), especialização necessária (agente de código separado do agente de análise), ou quando um único agente com muitas tools fica confuso. Desvantagem: orquestração complexa, mais latência, debugging difícil. Começar com agente único e só dividir quando justificado.ver conceito →

A.Assistente que augmenta o humano em vez de substituir: GitHub Copilot (completa código), Notion AI (melhora texto), Cursor (edita arquivos). Diferente de agente autônomo: o humano sempre aprova as ações. Padrão: show diff, human approves, apply. Mais seguro e confiável que agentes autônomos para casos de uso de produção.ver conceito →

A.Tracing de cada passo do agente: qual tool foi chamada, com quais args, qual o resultado, quanto tempo levou. LangSmith, Braintrust, ou Arize para tracing. Métricas: taxa de sucesso por task type, número médio de steps, custo por tarefa. Alertas para: loop detection, custo anômalo, taxa de erro acima do threshold.ver conceito →

A.Cache por similaridade semântica: gerar embedding da query, verificar se existe query similar em cache (threshold ~95% similarity), retornar resposta cacheada se sim. Diferente de cache exato (string match), semantic cache encontra "Como fazer login JWT" como cache hit de "Tutorial de autenticação com token". Reduz custos em 40-60% em apps de Q&A com queries repetitivas. GPTCache, Langchain semantic cache.ver conceito →

A.Classificar a query antes de chamar o modelo principal: query simples (extração, formatação, classificação) → modelo barato. Query complexa (raciocínio, código, análise) → modelo caro. A classificação pode ser feita com um modelo muito barato (GPT-4o-mini) ou com regras simples (tamanho do input, palavras-chave). RouteLLM é uma lib open-source para isso.ver conceito →

A.Prefixo do prompt (system prompt + documentos) pode ser cacheado por 5 minutos na Anthropic. Chamadas subsequentes que usam o mesmo prefixo pagam ~10% do custo para os tokens cacheados. Para apps com system prompts longos (1000+ tokens) ou RAG context inserido no prompt, o saving pode ser de 70-80%. Marcar com `cache_control: { type: "ephemeral" }`.ver conceito →

A.Ref no elemento final da lista de mensagens + useEffect que chama scrollIntoView toda vez que messages muda: `useEffect(() => { bottomRef.current?.scrollIntoView({ behavior: "smooth" }) }, [messages])`. Atenção: só fazer auto-scroll se o usuário não scrollou para cima manualmente — verificar se está próximo do bottom antes de scrollar.ver conceito →

A.react-markdown + remark-gfm para markdown básico. Para blocos de código com syntax highlight: substituir o componente code do react-markdown por react-syntax-highlighter. Adicionar botão de cópia em cada bloco de código. A maioria dos LLMs gera markdown — sempre parsear a resposta, nunca exibir como texto cru.ver conceito →

A.Adicionar botões 👍/👎 em cada mensagem do assistente. Salvar o feedback com o messageId e a resposta completa no backend. Usar para: melhorar prompts (análise de thumbs down), criar golden dataset para evals, identificar queries problemáticas. LangSmith e Braintrust têm UI de feedback integrada.ver conceito →

A.✅ Busca entender diretamente após a reunião, com tom informal. Aborda a pessoa em particular, com curiosidade e sem julgamento. ❌ Não reporta à liderança antes de tentar (escalada prematura). ❌ Não pergunta no grupo (exposição pública). ❌ Não mantém distância "por respeito" (omissão).ver conceito →

A.✅ Chama para conversar diretamente e entende o que está acontecendo. Confronta o problema de frente, sem audiência, sem retaliação. ❌ "O tempo acerta" = evitação. ❌ "Fazer o mesmo com ele" = passivo-agressivo. ❌ Escalar para o gestor sem ter tentado = escalada prematura.ver conceito →

A.✅ Constrói com ele um novo modelo que preserve o melhor das duas ideias. Síntese > disputa. ❌ Buscar dados para provar que sua ideia é melhor = ego disfarçado de rigor. ❌ Votar no time = democracia não resolve mérito técnico. ❌ Ceder para não perder tempo = falsa eficiência com ressentimento acumulado.ver conceito →

A.✅ Renegocia prazos, define blocos de foco e avisa o time sobre sua organização. Os 3 pilares: renegociação (expectativas alinhadas), blocos de foco (execução profunda, não multitarefa), comunicação proativa. ❌ Tentar equilibrar todas = cinco coisas mal feitas. ❌ Priorizar pela visibilidade = jogo político, não impacto real.ver conceito →

A.✅ Sugere redistribuir esforços para salvar o todo. Mentalidade de time: não se acomoda ao terminar a parte própria, pensa no resultado coletivo. ❌ Tentar compensar sozinho = martírio ineficiente. ❌ Só comunicar que terminou = faz o mínimo quando o time precisa de mais. ❌ "Respeitar os limites dos outros" nessa situação = desengajamento disfarçado.ver conceito →

A.✅ Cria rituais próprios para manter estabilidade e revisar entregas mesmo com o cenário mutável. Autogestão: não depende do gestor para ter clareza, constrói seu próprio sistema de revisão periódica e critérios de priorização. ❌ "Faz o que der" = sem critério nem ownership. ❌ Só avisar e aguardar = paralisa esperando o gestor resolver.ver conceito →

A.✅ Fala com gestor sobre o interesse e pergunta o que precisa desenvolver para estar pronto. Os 3 elementos: ambição declarada + autoconsciência (pode não estar pronto) + orientação a desenvolvimento. ❌ Candidatar imediatamente = arrogância sem contexto. ❌ Esperar ser reconhecido = passividade. ❌ "Não arriscar" = autossabotagem.ver conceito →

A.✅ Pergunta para líder e time, observa, aprende rápido e se adapta pelo contexto. As 3 virtudes: humildade para perguntar + observação ativa + aprendizado por imersão. ❌ Solicitar treinamento formal = paralisia em contexto temporário. ❌ Replicar processos anteriores = arrogância metodológica. ❌ Disfarçar insegurança = bloqueia o aprendizado.ver conceito →

A.✅ Analisa o que poderia ter feito diferente, compartilha com o time e segue em frente. Os 3 pilares: accountability (olha para dentro), aprendizado coletivo (compartilha, não guarda), resiliência (segue, não rumina). ❌ Focar nos resultados alcançados = spin defensivo. ❌ Analisar só fatores externos = fuga de responsabilidade. ❌ Passar por cima = zero aprendizado.ver conceito →

A.✅ Valida informalmente com colegas, prototipa versão pequena e coleta feedback. O ciclo lean: testa → mede → aprende → chega para cima com dados. ❌ Guardar para "o momento certo" = procrastinação com nome bonito. ❌ Apresentar direto para a liderança sem teste = aposta sem evidência. ❌ Escrever documento minucioso sem validação = over-engineering antes de qualquer dado.ver conceito →

A.✅ Notifica imediatamente todos os envolvidos, aguarda instruções e não interfere sem autorização. Os 3 princípios: urgência (notifica imediatamente), limite de autonomia (não age sem ok em sistema crítico), responsabilidade coletiva (não some). ❌ Buscar alternativas sem autorização = pode transformar queda em perda de dados. ❌ Esperar segunda-feira = sistema fora o domingo inteiro é impacto real.ver conceito →

A.✅ "Um colaborador participou de uma reunião sem convite prévio." — contraexemplo direto que quebra a premissa universal P→C. ❌ "Alguns recusaram convites" = fala de C→não participou, não afeta a regra. ❌ "Todos os convidados participaram" = fala do sentido inverso (C→P), não contradiz P→C.ver conceito →

A.✅ "O plano não foi aprovado." — modus tollens em cadeia: ¬Contratação → ¬Verba → ¬Plano. ❌ "Não é possível concluir" = errado, a lógica permite conclusão certa. ❌ "A verba não foi liberada" = verdade mas é só o primeiro passo; a conclusão completa é mais forte.ver conceito →

A.✅ João é líder e ignora o impacto emocional — contraexemplo direto à regra universal. ❌ Pedro (colaborador que ignora) = não é líder, fora do escopo. ❌ André (líder que reconhece mas não age) = reconhece o impacto, não ignora — não viola a premissa.ver conceito →

A.✅ Tiago não foi avisado. Raciocínio: Laura presente contradiz "Tiago avisado→Laura ausente", logo ¬Tiago avisado. Por consequência, ¬Pedro presente. ❌ "Pedro estava presente" = modus tollens prova o contrário. ❌ "Marta mentiu" = sem base lógica alguma no problema.ver conceito →

A.✅ "Quem não joga xadrez não é gestor." — contrapositiva direta de Gestor→Xadrez, logicamente equivalente. ❌ "Todos com lógica são gestores" = a premissa 3 contradiz diretamente. ❌ "Existem jogadores de xadrez que não são gestores" = não pode ser derivado com certeza.ver conceito →

A.✅ "Trabalhar muitas horas pode aumentar a produtividade." — reintroduz as horas como fator determinante, exatamente o que o texto nega. O "pode" é a armadilha que soa moderado mas ainda coloca horas como variável de aumento. ❌ As demais são paráfrases fiéis da ideia central.ver conceito →

A.✅ "Ausência de conflito é sempre um bom sinal de alinhamento." — viola duas coisas: (1) o texto usa "pode" (probabilístico), não "sempre" (absoluto); (2) o texto trata ausência de conflito como possível sinal negativo, não positivo. ❌ As demais são corolários válidos do texto.ver conceito →

A.✅ "O sucesso está na filtragem, não na quantidade." — paráfrase precisa da essência do texto. ❌ "Evitar ideias ruins desde o início" = o texto fala em descartar rapidamente, não em evitar gerar. ❌ "Quantidade é irrelevante" = o texto diz que não é a medida, não que é irrelevante — generalização excessiva.ver conceito →

A.✅ "A percepção de produtividade caiu porque o volume de entregas aumentou." — pega dois eventos correlacionados e cria causalidade direta e invertida. O texto diz que a causa é outra (fatores subjetivos). É o clássico post hoc: A e B aconteceram juntos, logo A causou B. ❌ As demais são inferências válidas do texto.ver conceito →

A.✅ "O uso efetivo do programa pode estar associado à retenção." — respeita a linguagem probabilística ("pode") e captura o ponto central: não é o programa em si, é o uso efetivo. ❌ "Ter um programa é suficiente para garantir retenção" = o texto nega explicitamente. ❌ "Empresas sem programa retêm menos" = generalização absoluta não suportada.ver conceito →

A.✅ 13 projetos. A: 24÷4=6, B: 24÷6=4, C: 24÷8=3. Total: 6+4+3=13. Como trabalham em paralelo, basta somar as entregas independentes — sem cálculo de ritmo conjunto.ver conceito →

A.✅ 3 erros. Sistema: c+e=8 e 5c-3e=16. Substituindo: 5(8-e)-3e=16 → 40-8e=16 → e=3. Verificação: 5×5=25, 3×3=9, 25-9=16 ✅ver conceito →

A.✅ R$3.375.000. Fórmula: 1.000.000 × (1,5)³ = 3.375.000. O expoente é 3 (não 4) porque o ano 1 já é a base — o crescimento ocorre nos anos 2, 3 e 4. Armadilha clássica: usar (1,5)⁴.ver conceito →

A.✅ R$60.000. Proporção inversa: pesos = valores trocados. X=6, Y=9, Z=15. Total: 30. Z=15/30 × 120.000 = R$60.000. Verificação: X=R$24k, Y=R$36k, Z=R$60k → total R$120k ✅ver conceito →

A.✅ 144 cm². Lado do quadrado: √36=6cm. Retângulo: 18×6=108cm². Total: 36+108=144cm².ver conceito →

A.Volume esperado em eventos/segundo no pico (Black Friday). Tudo dimensiona a partir disso. Em seguida: perda de evento é tolerável? Latência aceitável? Quem consome — marketing, BI, ML? Cloud preferida? LGPD?ver conceito →

A.0-10min: requisitos + estimativas. 10-20min: 5 caixas-camada de cima para baixo com setas. 20-40min: aprofundar 2-3 pontos (contrato de evento, broker+processor, modelo OLAP). 40-50min: camada transversal (CI/CD, observabilidade, SLO). 50-60min: trade-offs e gargalos.ver conceito →

A.Hot path: caminho quente em segundos para operação (Kafka → Flink → ClickHouse → Dashboard). Cold path: caminho frio em batch para análise histórica (Lake → Warehouse → BI/ML). Arquitetura Lambda/Kappa. Dois caminhos para necessidades diferentes.ver conceito →

A.sendBeacon é assíncrono, não bloqueia o unload da página e o browser garante o envio mesmo se a aba fechar. fetch() durante unload é cancelado pelo browser. Para purchase event (crítico), sendBeacon evita perda quando o usuário fecha a aba após confirmar compra.ver conceito →

A.dataLayer é uma camada intermediária (geralmente injetada pelo GTM) onde todo evento passa antes de sair do browser. Padronizar no schema GA4 desacopla a página das ferramentas de destino — você troca o GA por outra ferramenta sem mexer no código da página.ver conceito →

A.Fila local em memória (com persistência em sessionStorage para sobreviver a navegação). Flush em 3 triggers: tamanho máximo (ex: 20 eventos), tempo máximo (ex: 5s) e antes do unload (com sendBeacon). Retry com backoff exponencial se o request falhar.ver conceito →

A.O cliente está esperando para liberar a fila local. Quanto mais rápido o collector responde, menos memória do browser fica ocupada com a fila e menor a chance de perder evento se a aba fechar. 204 (No Content) é o status correto: recebido com sucesso, sem body de resposta.ver conceito →

A.Stateless: não guarda nada localmente, todo evento vai para o broker (Kafka). Atrás de um Load Balancer com autoscaling baseado em CPU/requests. Cada instância é idêntica e descartável. Se uma cai, o LB redireciona para outra sem perda.ver conceito →

A.Cookie de consent enviado no request. Se ausente ou negado: descarta evento (response 204 mesmo assim, sem persistir). Se parcial: anonimiza PII (hash do user_id, remove IP). Política de retenção: dados crus expiram em N dias automaticamente no S3 via lifecycle policy.ver conceito →

A.Session_id distribui melhor (mais valores únicos), evita hot partition (um usuário muito ativo concentrando tráfego), e preserva ordem por sessão — que é o que importa para sessionização. user_id seria útil se você precisasse processar tudo do usuário junto, mas sessões são naturalmente isoladas.ver conceito →

A.Sinal que diz "todos os eventos com timestamp < X já chegaram (com 95% de certeza)". Permite fechar janelas de sessionização tolerando eventos atrasados. Watermark agressivo = janelas fecham cedo, perde eventos atrasados. Watermark conservador = latência maior mas captura tudo.ver conceito →

A.State backend (RocksDB) guarda event_ids já vistos com TTL (ex: 1h). Cada evento entrante consulta o state. Se já existe, descarta. TTL evita crescimento infinito. RocksDB local = rápido (sem rede). Para dedupe global cross-partition, usar partição por event_id_prefix.ver conceito →

A.ClickHouse é colunar: armazena cada coluna separadamente, otimizado para agregação (count, sum, avg) sobre bilhões de linhas. Postgres é row-based: ótimo para OLTP (uma linha por vez) mas lento para analytics. ClickHouse comprime ~10x mais e roda agregações 100-1000x mais rápido em datasets grandes.ver conceito →

A.Dois caminhos paralelos: speed layer (stream processing, segundos de latência, aproximado) e batch layer (reprocessamento periódico, exato). Query layer combina os dois. Resolve o trade-off entre latência e correção. Kappa simplifica: só stream processing, com replay para recalcular.ver conceito →

A.Replay: se você descobrir um bug no processor depois de 6 meses, pode reprocessar todos os eventos crus do Lake e regerar OLAP/Warehouse com a regra corrigida. Sem o raw, esses 6 meses de dados estão corrompidos para sempre. Imutável + barato (Parquet em S3) = garantia futura.ver conceito →

A.Idempotência = mesma operação aplicada N vezes tem o mesmo efeito de 1 vez. Em tracking: event_id (UUID gerado no cliente) é a chave. Broker pode entregar 2x se a confirmação se perder; processor consulta state (RocksDB) e descarta se já viu esse event_id. TTL no state evita crescimento infinito.ver conceito →

A.Só sob pico extremo (Black Friday picando 5x acima do esperado). Amostre eventos de baixo valor primeiro: page_view, scroll. NUNCA amostre purchase, add_to_cart, ou qualquer evento que vire métrica de receita. Amostragem com hash do session_id para que análise por sessão ainda seja válida.ver conceito →

A.At-least-once: broker garante entrega, mas pode duplicar se a confirmação se perder. Implementação simples e robusta — Kafka padrão. Exactly-once: nenhuma duplicação possível. Custosa: precisa de transações distribuídas. Em tracking, at-least-once + idempotência (event_id) = efeito de exactly-once a custo baixo.ver conceito →

A.(1) Volume esperado em eventos/segundo no pico (Black Friday)? (2) Perda de evento é tolerável e qual a latência aceitável? (3) Operação em tempo real ou só análise posterior? (4) Quem consome — marketing, BI, ML, todos? (5) Restrição de cloud, custo ou requisito LGPD? (6) Aproveito GTM/GA existente ou construo do zero?ver conceito →

A.Pipeline: event pipeline, collector, sendBeacon, batching, ingestion. Streaming: Kafka, partition, back-pressure, Flink, sessionização, watermark, event time. Confiabilidade: idempotência, event_id, dedupe, schema registry, data contract. Dados: data lake, OLAP, ClickHouse, hot/cold path, Lambda/Kappa. Frontend/VTEX: VTEX IO, Pixel App, dataLayer, GA4. Infra: GitHub Actions, Terraform, k6, Playwright, SLO.ver conceito →

A."Resumindo os trade-offs: (1) Para resiliência, sendBeacon + idempotência por event_id. (2) Hot path em ClickHouse (segundos), cold path em Lake/Warehouse (batch). (3) Schema Registry para evolução sem quebrar. Se o pico triplicar, o gargalo é o processor; mitigação: scale Flink + amostrar eventos de baixo valor. Riscos: schema drift, perda de evento em rede instável, custo do OLAP em alta cardinalidade."ver conceito →

A.IntersectionObserver no último item da lista para detectar visibilidade próxima do fim. Quando dispara, fetch da próxima página. Estado paginado em useState/useReducer. Throttle no observer para não disparar múltiplos requests. Skeleton enquanto carrega. Track view_item_list para cada batch carregado.ver conceito →

A.Pixel App: você cria uma app de tipo "pixel" que recebe eventos do VTEX Store via window.vtex events. Não toca em componentes existentes — só escuta. Vantagem: instalação por loja sem rebuild da storefront, fácil de A/B testar duas implementações.ver conceito →

A.ThemeExtension app blocks: moderno, declarativo, merchant ativa no theme editor, performático. ScriptTag: legacy, injeta script no global, sem controle do merchant. Para tracking moderno em Shopify: usar Web Pixel API (sandbox seguro, performance otimizada) em vez de ScriptTag.ver conceito →

A.Hydrogen: componentes Shopify prontos (Money, Image, ProductProvider), client GraphQL otimizado, deploy nativo no Oxygen com cache no edge, integração com Shopify Checkout sem código. Next.js: você implementa tudo do zero mas tem flexibilidade total e ecossistema React maior. Para storefront pura: Hydrogen. Para app híbrido com mais que loja: Next.js com SDK Storefront.ver conceito →

A.Oxygen é o hosting edge do Shopify para Hydrogen. Roda em workers globais (similar Cloudflare). Inclui cache automático de queries GraphQL, deploy via GitHub integration, e previews por branch. Gratuito para lojas Shopify Plus. Não obrigatório — Hydrogen também roda em Vercel/Netlify/Cloudflare Workers.ver conceito →

A.Hydrogen NÃO implementa o checkout — você redireciona para o checkout hospedado do Shopify (com domínio próprio configurado). Vantagem: PCI compliance, fraud detection, payment methods já configurados. Desvantagem: você perde controle visual da última etapa. Para checkout customizado completo, precisa Shopify Plus + Checkout Extensibility.ver conceito →

A.Sections: blocos modulares reutilizáveis (hero, product-grid, testimonials). Configuráveis pelo merchant no theme editor via schema JSON. Blocks: itens dentro de sections, repetíveis e ordenáveis. Ex: section "image-with-text" pode ter blocks "heading", "text", "button". Tudo declarativo, zero deploy para mudanças visuais — merchant faz no admin.ver conceito →

A.Use `{{ object | json }}` para serializar e ver o conteúdo. Liquid não tem stack trace — erros silenciam. Shopify CLI tem hot reload local com `shopify theme dev`. Use comment tags `{% comment %} ... {% endcomment %}` para isolar problemas. Para perfil: aba Network do DevTools (templates renderizam server-side).ver conceito →

A.OS 2.0 (Liquid moderno com Sections Everywhere, App Blocks, Metaobjects): merchants mantêm controle no theme editor, time pequeno, prazo curto, customização média. Hydrogen: time React experiente, performance crítica, controle total do front, marca premium com identidade visual forte. OS 2.0 é o caminho default; Hydrogen quando OS 2.0 não basta.ver conceito →

A.Polaris é o único que se integra ao visual do admin Shopify nativamente. Se seu app é embedded, USE POLARIS — sem alternativa razoável. Material UI ou Chakra fariam o app parecer "fora do lugar". Se seu app é externo (não embedded), aí qualquer DS serve, mas Polaris ainda é boa escolha para merchants familiarizados.ver conceito →

A.Tokens são valores semânticos exportados como CSS vars: `--p-color-bg-surface`, `--p-text-heading-md-font-size`, `--p-space-400`. Você usa no CSS customizado e eles seguem o tema (light/dark/contrast) automaticamente. Tokens existem em camadas: primitivos (gray-100) → semânticos (color-bg-fill) → componentes (button-bg).ver conceito →

A.App Bridge: SDK do Shopify para apps embedded se comunicarem com o admin (navegação, modais, redirects). Polaris: UI dos componentes. Funcionam juntos: App Bridge controla o "chrome" (topbar, navigation) e Polaris os componentes internos. `<AppProvider linkComponent={ShopifyLink}>` substitui `<a>` por navegação client-side do Shopify.ver conceito →

A.Standard events: page_viewed, product_viewed, collection_viewed, search_submitted, product_added_to_cart, cart_viewed, checkout_started, checkout_address_info_submitted, checkout_contact_info_submitted, checkout_shipping_info_submitted, checkout_payment_info_submitted, checkout_completed. Schema unificado (event_name, timestamp, data). DOM events customizados: você pode emitir manualmente via `analytics.publish()`.ver conceito →

A.O código do pixel roda em um iframe ou Web Worker isolado — sem acesso ao DOM da loja, sem acesso a outras Web Pixels, sem `window` global. APIs disponíveis: `analytics.subscribe(event, handler)`, `fetch` (com CSP restrita), `localStorage` próprio do sandbox. Resultado: pixel não consegue corromper a loja nem se intrometer em outros pixels.ver conceito →

A.1) Criar um app Shopify do tipo `web_pixel_extension`. 2) Implementar o handler subscribing aos eventos relevantes. 3) Merchant instala o app no admin. 4) Decomissionar o ScriptTag antigo (remover do app, ele se desinstala automaticamente). Resultados: ~5-10% mais eventos capturados, especialmente em checkout. Custo: migração leva 1-2 sprints dependendo da complexidade do tracking atual.ver conceito →

A.Implementar heartbeat: servidor manda ping a cada 30s, cliente responde pong. Se o client não receber ping em 60s, fecha e reabre a conexão com backoff exponencial (1s, 2s, 4s, max 30s). Adicionar reconnect logic no onclose handler. socket.io faz isso por padrão — é um dos motivos de usá-lo.ver conceito →

A.Automaticamente via EventSource API: quando a conexão cai, o browser reconecta em ~3s por padrão e envia o header Last-Event-ID com o ID do último evento recebido. O servidor usa esse ID para retransmitir eventos perdidos. Para isso funcionar, você precisa implementar um ID incremental nos eventos e guardar histórico no servidor.ver conceito →

A.WebSocket é stateful — conexão fica em um servidor específico. Para escalar: usar Redis Pub/Sub ou um message broker (Kafka) como bus compartilhado. Quando evento chega em server A, ele publica no Redis; todos os servidores subscrevem e entregam para seus clientes conectados. Socket.io tem adapter de Redis pronto. Sem isso, sticky sessions são necessárias (pior).ver conceito →

A.Guardar snapshot do estado anterior: `const prev = queryClient.getQueryData(key)`. No catch da mutation: `queryClient.setQueryData(key, prev)`. Com React Query, useMutation tem callbacks onMutate (salva prev, aplica optimistic), onError (rollback), onSettled (invalida query para buscar dado real). O useOptimistic do React 19 faz isso automaticamente.ver conceito →

A.Na onSettled ou onSuccess, invalidar a query para refetch do dado real: `queryClient.invalidateQueries({ queryKey: key })`. O dado optimistic é substituído pelo dado real. Se o servidor enriquece o dado (ex: adiciona um campo `id` ao item criado), o optimistic temporário some e o real aparece — pode causar um flash visual. Solução: usar um id temporário (uuid) que é substituído pelo id real.ver conceito →

A.Problema clássico de consistency. Abordagens: Last-write-wins (mais simples, pode perder dados), OT (Operational Transformation, Google Docs), CRDT (Conflict-free Replicated Data Types, Figma, Notion). Para maioria dos apps: last-write-wins com timestamp é suficiente. Para colaboração em tempo real em documentos: CRDT com bibliotecas como Yjs ou Automerge.ver conceito →

A.Cache Only (só cache, sem rede — assets imutáveis com hash no nome). Network Only (sempre rede — dados sensíveis). Cache First (cache → rede se miss — assets estáticos). Network First (rede → cache se offline — dados dinâmicos). Stale-While-Revalidate (cache imediato + rede em background para atualizar — melhor para dados que podem ter um delay). Workbox implementa todas como strategies prontos.ver conceito →

A.Registrar um sync tag quando a ação falha por falta de rede: `navigator.serviceWorker.ready.then(sw => sw.sync.register('send-message'))`. O browser chama o evento sync no Service Worker quando a rede volta, mesmo se o app está fechado. O SW processa a fila salva no IndexedDB. Limitação: não é suportado no iOS/Safari — nesses casos, usar o evento online para disparar a sync manualmente.ver conceito →

A.Cache busting: incluir hash no nome dos assets (webpack/Next.js fazem isso automaticamente). Ao deployar novo SW: ele instala mas fica waiting até todas as abas fecharem. Para forçar imediato: `self.skipWaiting()` no install + `clients.claim()` no activate. Versionamento de cache: ao ativar novo SW, deletar caches antigos pelo nome (incluir versão no nome do cache). Workbox tem `precacheAndRoute` que gerencia tudo.ver conceito →

A.TanStack Virtual com measureElement: usar um ref no elemento renderizado, o VirtualItem recebe `measureRef` para o virtual item medir após render. Internamente usa ResizeObserver. Passar `estimateSize` como fallback antes de medir. Ou react-window com VariableSizeList + CellMeasurer da react-virtualized. O approach do TanStack é mais moderno e não precisa de ref callback manual.ver conceito →

A.Intersection Observer no último item visível (ou sentinel element após a lista): quando fica visível, disparar fetchNextPage() do React Query infinite query. O virtual list precisa saber o totalCount estimado para calcular o scrollbar. Padrão: `count = hasMore ? items.length + 1 : items.length` — o +1 é um placeholder que, quando fica visível, carrega mais.ver conceito →

A.Difícil mas possível. O problema: itens saem do DOM durante o drag, quebrando a animação. Soluções: (1) desativar virtualização durante drag (se lista for pequena o suficiente), (2) usar dnd-kit com estratégia de virtualização específica, (3) manter items do drag 'pinados' no DOM fora da virtual window. @dnd-kit/sortable tem um exemplo com TanStack Virtual.ver conceito →

A.Guardar referência ao objeto Marker ou Layer do Mapbox e atualizar via API imperativa do Mapbox (sem React re-render). `markerRef.current.setLngLat([lng, lat])` para Markers. Para Source GeoJSON: `map.getSource('drivers').setData(newGeoJSON)` — Mapbox só atualiza os dados na GPU, sem tocar no DOM. Isso mantém animações suaves a 60fps.ver conceito →

A.Usar Mapbox Cluster Source: `type: 'geojson', cluster: true, clusterRadius: 50`. Mapbox calcula clusters no worker thread. Para interação: ao clicar num cluster, zoom para mostrar os items individuais com `map.flyTo`. Para clusters customizados em React: supercluster library + calcular clusters no useMemo quando viewport muda (bounds + zoom).ver conceito →

A.Mapbox Fill Layer para polígonos (surge pricing zones, delivery areas). GeoJSON Polygon ou MultiPolygon como source. Para interatividade: `map.on('click', 'geofence-layer', handler)` para detectar clicks. Para verificar se um ponto está dentro de um polígono no cliente: turf.js `booleanPointInPolygon()`. Para polígonos dinâmicos (desenhados pelo usuário): mapbox-gl-draw plugin.ver conceito →

A.Seletores granulares no Zustand: `const position = useDriverStore(s => s.position)` — só re-renderiza quando `position` muda. O mapa subscreve só à position. O ETA subscreve só ao ETA calculado. O header subscreve só ao status. Sem selector: `useDriverStore()` re-renderiza em qualquer mudança de qualquer campo. Com Jotai: atoms granulares por campo — position atom, status atom, etc.ver conceito →

A.React Query + SSE/WebSocket: o servidor publica eventos; o client subscreve e chama `queryClient.setQueryData` para atualizar o cache imediatamente (sem refetch). A query key é a fonte da verdade: qualquer componente que usa `useQuery(['ride', id])` recebe a atualização. Para mutations: optimistic update (ver concept 117). O benefício: React Query gerencia loading, error, e stale state automaticamente.ver conceito →

A.Zustand middleware persist: `create(persist(store, { name: 'ride-state', storage: createJSONStorage(() => localStorage) }))`. Configurar `partialize` para persistir só o necessário (não posições transitórias). Na reabertura do app, verificar com o servidor se a corrida ainda está ativa via API (`GET /ride/current`). Se sim, restaurar estado e reconectar SSE. Se não, limpar estado local.ver conceito →

A.Two-step permission: primeiro mostrar uma UI própria explicando o benefício ('receba alertas quando seu pedido sair para entrega'). Só se o usuário clicar em 'Ativar' na UI sua, chamar Notification.requestPermission(). Se o browser perguntar e o usuário aceitar, registrar a subscription. Não chamar requestPermission() direto sem consentimento explícito — cria bad UX e o usuário rejeita por reflexo.ver conceito →

A.Usar web-push library (Node.js): `webpush.sendNotification(subscription, JSON.stringify(payload))`. O payload tem: title, body, icon, badge, actions, data (para deep link ao clicar). No Service Worker: `self.addEventListener('push', e => { const data = e.data.json(); self.registration.showNotification(data.title, data) })`. Ao clicar: `self.addEventListener('notificationclick', e => { clients.openWindow(e.notification.data.url) })`.ver conceito →

A.O endpoint pode expirar (usuário troca browser, reinstala, limpa dados). Ao tentar enviar: web-push retorna 410 Gone — remover a subscription do banco. Implementar o cleanup no catch do sendNotification. Para garantir subscriptions atualizadas: ao montar o app, comparar a subscription atual do browser com a salva no servidor e atualizar se diferente via PUT /api/push-subscription.ver conceito →