Perguntas de entrevista React Native

Qual é a diferença entre props e state no React Native?

Props são dados só de leitura passados por um componente pai, e pertencem a quem os passa; state é local ao componente e muda ao longo do tempo via useState ou useReducer. Um componente que recebe os mesmos props duas vezes sem mudança de state deveria renderizar a mesma saída — é isso que torna os props previsíveis. Passar setters para baixo como props ("elevar o state") é a forma padrão de um filho disparar uma mudança de state que não é dele.

O que é JSX, e para que ele realmente compila?

JSX é açúcar sintático para chamadas de React.createElement — <View style={styles.box}>{text}</View> vira uma árvore aninhada de objetos elemento, não nós DOM reais, porque no native não existe DOM. A transformação do Babel converte as tags em chamadas de função antes mesmo do JS rodar, então JSX é uma conveniência de build-time, não um recurso de runtime. No React Native esses objetos elemento acabam descrevendo uma hierarquia de views nativas em vez de HTML.

O que `useState` e `useEffect` fazem, e quando o efeito roda?

useState dá a um componente um pedaço de state e um setter que dispara um re-render quando chamado; useEffect roda um efeito colateral depois que o render é commitado, e só roda de novo quando algo no array de dependências mudou. Esquecer uma dependência é a causa mais comum de closures obsoletos — o efeito continua referenciando o valor do render em que foi criado. Um array de dependências vazio significa "rodar uma vez ao montar", e nenhum array significa "rodar depois de cada render".

Como funciona a estilização no React Native, e por que o Flexbox se comporta diferente da web?

Não existe CSS — estilos são objetos JS criados com StyleSheet.create, mapeados por baixo para propriedades de views nativas. O Flexbox continua sendo o motor de layout, mas flexDirection é column por padrão em vez de row, não há cascata CSS, e as unidades são pixels independentes de densidade sem unidade, não px/em/rem. Larguras em porcentagem, flex: 1 para preencher o espaço restante, e justifyContent/alignItems para alinhamento cobrem a maioria dos layouts reais.

Como funciona a navegação com React Navigation, e o que o deep linking acrescenta?

O React Navigation modela o app como uma árvore de navegadores — stack, tab, drawer —, cada tela registrada com um nome, e navigation.navigate('Screen', params) move entre elas mantendo uma pilha de histórico para o gesto de voltar. O deep linking mapeia um esquema de URL externo ou um universal link para uma tela específica com parâmetros, então uma notificação push ou um link da web pode levar o usuário direto para, digamos, uma tela de detalhe de pedido em vez da tela inicial do app. Fazer isso direito envolve lidar tanto com um cold start (app não está rodando) quanto com uma retomada a partir de um link com o app já aberto.

O que é o bridge, e no que ele difere do JSI e da New Architecture?

Na arquitetura antiga, JS e código nativo não compartilham memória — eles se comunicam pelo bridge, uma fila de mensagens assíncrona, em lotes e serializada em JSON, o que significa que toda chamada nativa carrega custo de serialização e latência. O JSI (JavaScript Interface) substitui isso por bindings diretos em C++, deixando o JS manter referências a objetos nativos e chamar seus métodos de forma síncrona, sem serialização. A New Architecture é construída sobre o JSI: TurboModules substituem os módulos nativos, e o Fabric substitui o antigo UI manager, ambos conseguindo falar com código nativo diretamente em vez de enfileirar pelo bridge.

Como você evita que uma `FlatList` longa fique travada?

Dê a cada item um keyExtractor estável, memoize o componente de linha com React.memo para que um re-render do pai não re-renderize cada linha, e evite funções e literais de objeto inline em renderItem, porque uma referência nova a cada render anula a memoização. getItemLayout pula uma passagem de medição quando a altura da linha é fixa, e windowSize/initialNumToRender/removeClippedSubviews trocam memória por fluidez de scroll. Para listas muito grandes ou complexas, o FlashList da Shopify resolve o mesmo problema com menos ajuste manual.

Quais são as diferenças reais entre construir para iOS e Android no React Native?

Safe areas, comportamento do teclado e estilização de sombras (props shadow* no iOS vs. elevation no Android) divergem o suficiente para que a paridade pixel a pixel precise de código específico de plataforma via Platform.select ou extensões de arquivo .ios.js/.android.js. Permissões, configuração de notificações push e limites de tarefas em background seguem as regras próprias de cada plataforma — os limites de execução em background do Android e a revisão mais rígida da App Store da Apple são restrições diferentes, não só APIs diferentes. Um módulo nativo escrito para uma plataforma precisa de uma contraparte real em Swift/Objective-C e Kotlin/Java antes de funcionar nas duas.

Como um release realmente sai — o que Metro, atualizações OTA e a revisão da store têm a ver uns com os outros?

O Metro empacota e serve o JS durante o desenvolvimento e o empacota dentro do binário do app para o release; ele não faz parte do que os usuários recebem, é só a ferramenta de build. Serviços de atualização OTA como CodePush ou Expo Updates enviam um novo bundle JS direto para os apps instalados sem revisão da App Store ou Play Store, o que é rápido para bugfixes, mas explicitamente proibido para qualquer coisa que mude código nativo ou ultrapasse o que a store considera "não é só conteúdo". Mudanças nativas — um novo módulo nativo, uma permissão, um bump de SDK — sempre exigem um build completo e um novo envio à store, então um time vive em duas velocidades: OTA para fixes só de JS, releases de store para tudo que é nativo.