Suor escorrendo na testa. O entrevistador do JPMC se inclina, olhos semicerrados no seu componente React puxando usuários falsos do JSONPlaceholder.
Desafios de código em entrevistas de React em bancos grandes como JPMC e Barclays? Menos sobre construir apps, mais sobre recitar hooks debaixo de pressão. Pega dados de uma API, renderiza uma tabela — simples, né? Errado. Eles cutucam por otimizações, race conditions, AbortControllers. É um teste de fogo disfarçado de pair-programming.
Aqui vai o código que eles te dão pra começar. useState básico pra users, loading, error. Um useRef pra IDs de request. AbortController à espreita.
A pergunta mais comum em entrevistas pra dev frontend é buscar dados de uma API e renderizar os elementos. Parece tarefa simples, mas o entrevistador pede melhorias e otimizações durante a pair-programming.
Essa frase resume tudo. No papel, moleza. Na hora, inferno.
Por que bancos piram nessas loucuras de fetch em React?
Olha só. Cliques rápidos no botão. getDetails numa linha de usuário. De repente, respostas se chocam — o dado da primeira chamada pisa no da segunda. UI defasada. Cidade das race conditions.
Entrevistador dá uma risadinha: ‘Conserta isso.’ Você pega o useRef, incrementa um requestId. Só atualiza o state se os IDs baterem. Pronto. Ou AbortController — explode fetches pendentes no unmount. Limpo, mas chato de acertar.
Mas aqui vai minha opinião quente, que o post original não tem: isso fede a cansaço de React de 2018. Lembra da era jQuery? Filas infinitas de .ajax, limpeza manual? Bancos como Barclays ainda treinam esse reflexo. Enquanto o mundo tá no React Query ou SWR — fetch de dados sem boilerplate. Essas entrevistas testam cicatrizes do passado, não ferramentas do futuro.
Resumindo? Gatekeeping com trivias.
Três states pedindo pra virar um só. Um objeto: { users: [], loading: false, error: null }. Mais limpo. Ou custom hook? Claro. Extrai a lógica do getUsers, memoiza o AbortController. Reutilização pura.
Race Conditions: AbortController ou Nada?
AbortController é a estrela. Fetch com signal: { signal: abortController.signal }. Unmount? abort(). Sem respostas zumbis.
AbortController cancela o request se o componente for desmontado antes da resposta chegar.
useRef combina com ele pra checagens de mounted — embora o StrictMode do React 18 vire unmount/remount como viagem ruim de ácido. Por que não só requestId? Mais simples, sem drama de polyfill no browser.
Entrevistador cutuca: ‘Mounted vs unmounted?’ Você manda ver no papo de cleanup functions. Eles acenam. Passou da vez.
Alerta de humor seco: É tipo ensinar criança a amarrar cadarço num mundo de Velcro. Funciona? Sim. Essencial? Discutível.
Custom Hooks: Porque useState é Muito Baunilha?
‘Declara um custom hook.’ Pânico total. Embrulha a loucura do fetch em useFetchUsers. Props pro ID. Cuida de loading, error, data. Genérico pra users ou singles.
Por que useState? Mutações simples. useReducer? Se a lógica do state explodir — updates otimistas, retries. Exagero aqui. Mas fala: ‘Escala melhor pra fluxos complexos.’
Botões. Sem arrows inline: onClick={getDetails}. Por quê? Escopo lexical, sem recriação por render. Ganha perf. Ou useCallback se for paranoico.
Por que não arrow functions nos botões e qual o propósito
Fãs de Typescript vibram. Interfaces pra Users, Address. Pedante, mas bancos amam redes de segurança estáticas.
Um parágrafo só: Esse código roda. Por pouco.
Agora a crítica. JPMC, Barclays — vocês contratam pra UIs de fintech que crasham no volume de trades? Mas entrevistas simulam apps de brinquedo. Aposta ousada: Em dois anos, AI pair-programmers tipo Cursor ou GitHub Copilot mandam ver nisso. Humanos? Vão entrevistar por arquitetura, não roleta de hooks. Acordem.
getDetails chama getUsers com ID. Troca array por objeto único, força pra [data]. Gordura, mas JSONPlaceholder é esquisito.
Tabela renderiza afiada: ID, name, username, email, botão details. Spinner de loading. Toast de
