Entendendo hierarquia de componentes nativos na prática
Passar o dia lidando com layout em React Native me ensinou uma coisa: a hierarquia de componentes nativos é muito mais traiçoeira do que parece nos tutoriais. O conceito básico é simples. Cada componente que você renderiza vira uma instância nativa do lado do iOS ou do Android. O React Native cria essa ponte entre o JavaScript e os componentes nativos, mas na hora de alinhar algo, você rapidamente percebe que não está mais no DOM — está num árbol de views controlado pelo sistema operacional.
em relação a hierarquia de componentes nativos
Quando eu comecei, achava que flexbox resolvia tudo. Resolvia tudo, exceto quando você precisa de uma interação específica que depende de como o iOS ou o Android interpretam a pilha de renderização. A hierarquia determina quem recebe toques, quem clipa o conteúdo, quem aplica transformações primeiro e um monte de coisas que só dão trabalho quando estão erradas. O problema real começa quando você usa componentes como ScrollView dentro de um layout aninhado. O ScrollView tem seu próprio comportamente de rolagem nativo, e se você não entender a hierarquia por baixo, vai gastar duas horas debugando por que um botão simplesmente não responde aos toques.
O que acontece é que o ScrollView, ao herdar a hierarquia de views, muitas vezes passa a interceptar eventos de toque antes que cheguem aos filhos dele. A solução não é complexa, mas não aparece em nenhum guia: use onStartShouldSetResponder nos elementos filhos para reivindicar o touch antes que o scroll tente consumi-lo. Funciona assim: Seu componente pai é um ScrollView. Dentro dele, você tem um botão. O botão não funciona porque o ScrollView está pegando o evento de toque para iniciar a rolagem. No elemento do botão, você coloca onStartShouldSetResponder retornando true. Pronto. O touch vai direto pro botão.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro ponto que ninguém explica direito é a diferença entre renderização no thread de UI e no thread principal. Componentes nativos, quando envolverem something pesado, podem bloquear a hierarquia inteira. O layout para de responder. E você fica olhando pra tela pensando que é bug de CSS. Eu caí nessa pegando vídeo em loop dentro de um modal com fundo semi-transparente. O React Native tentava renderizar o vídeo nativo num thread que competia com o layout do modal. O resultado era um flickering absurdo em iPhones mais antigos. A solução foi mover o vídeo pra fora da hierarquia visual, usando position absolute e mantendo-o num nível topo da stack de views. Assim o compositor do iOS tratava cada camada separadamente.
Aqui vai uma regra que eu segui por anos sem questionar e que quebrei recentemente: não aninhe ScrollView dentro de View com flex:1 esperando que ela cresça automaticamente. Isso funciona em ambientes controlados, mas em listas dinâmicas com altura variável, o cálculo de layout do nativo entra em loop. O Android em particularadora o tempo todo recalculando a altura e nunca convergindo. A alternativa mais estável é usar keyExtractor adequado e confiar no FlashList ou no FlatList nativo, que gerencia a hierarquia internamente de forma muito mais eficiente do que você faria manualmente. O custo é um pouco menos de controle individual sobre cada item, mas a compensação em performance é clara.
Se você está migrando do web pro mobile, lembre-se: a hierarquia de componentes nativos não é uma abstração perfeita do DOM. Ela aproxima, mas não idêntica. Aceitar isso desde o início evita metade dos problemas. A outra metade vem dos edge cases que eu descrevi aqui, mas que só aparecem depois que você já gastou três dias num projeto. O resto é experimentação e registro do que funciona. Não existe manual definitivo, porque cada dispositivo e cada versão do sistema operacional interpreta a hierarquia de forma ligeiramente diferente.
