Layout no React Native não é CSS, então vamos acertar isso de uma vez
A maioria dos devs chega no RN achando que Flexbox funciona igual na web. Funciona, só que com um comportamento ligeiramente diferente e mais restritivo. O flexDirection padrão já vem como column em vez de row, o que quebra todo mundo pela primeira vez. E o alignItems centraliza por padrão, não alinha à esquerda como no browser. Eu passei duas semanas refazendo layouts inteiros porque não entendia por que um View não crescia verticalmente quando eu esperava que crescesse. O problema era simples: sem altura definida e sem flexWrap, o componente filho simplesmente não ocupava espaço extra. A solução foi adicionar flex: 1 no container pai e definir height ou flexGrow no filho, dependendo do que eu precisava.
melhor formula para rn
O padrão que eu uso em praticamente todo projeto hoje segue essa estrutura básica: Container principal usa flexDirection: 'column', justifyContent e alignItems conforme a necessidade. Cada seção interna vira um View separado com padding e margin bem definidos, nunca dependendo do tamanho do filho para calcular o tamanho do pai. Todo componente reutilizável recebe uma prop style personalizada que se sobrepõe ao estilo padrão, usando spread operator.
O código fica algo assim: const styles = StyleSheet.create({
container: { flexDirection: 'column', padding: 16, }, section: { backgroundColor: '#f5f5f5', borderRadius: 8, padding: 12, marginBottom: 16, },
button: { backgroundColor: '#007AFF', borderRadius: 6, paddingVertical: 12, paddingHorizontal: 24, alignItems: 'center', }, text: { fontSize: 16, color: '#333', },
👉 Clique no botão abaixo para saber mais sobre o assunto!
}); Isso parece simples mas é onde a maioria erra. A questão é que no RN, margin e padding não são intercambiáveis como na web. Margin empurra outros elementos, padding expande a área clicável e o fundo do componente. Trocar um pelo outro de propósito errado causa aquele bug chato onde o toque não é detectado na borda do botão.
Outro ponto que pouca gente menciona: FlatList dentro de ScrollView. Eu já vi isso em centenas de projetos e sempre dá problema. O ScrollHandler não consegue distinguir o scroll da lista do scroll da página, então você acaba com ambos rolando des sincronizados. A solução é remover o ScrollView externo e deixar a FlatList cuidar de tudo sozinha, ou usar o nestedScrollEnabled do Android junto com uma solução customizada no iOS. Performance com listas grandes também merece atenção. Use keyExtractor sempre, mesmo que o ID seja óbvio. Eu vi um projeto onde a lista de 500 itens estava redimensionando e recalculando layouts a cada scroll por causa de keyExtractor faltando. A lista travava em dispositivos mais antigos porque o ReactNative tentava renderizar tudo de novo a cada interação.
O useMemo para cálculos dentro de componentes de lista é essencial. Sem ele, cada re-render do pai recalcula a mesma coisa. No meu último projeto, um cálculo de preço com três fórmulas diferentes dentro do renderItem estava sendo executado 300 vezes por frame em telas grandes. Depois de aplicar useMemo com as dependências corretas, o consumo de CPU caiu drasticamente. Estilos inline funcionam mas geram garbage collection constante. Cada vez que o componente re-renderiza, o objeto de estilo é recriado. Para componentes que renderizam frequentemente, isso se acumula e começa a causar lag perceptível em dispositivos de entrada. Use StyleSheet.create sempre que possível, exceto em casos muito específicos onde o estilo depende de props que mudam a cada render.
Um detalhe importante sobre o TouchableOpacity: ele não herda pointerEvents corretamente em versões antigas do RN. Se você precisa desabilitar o toque em um botão dentro de outro touchable, precisa usar pointerEvents="none" explicitamente. Sem isso, os eventos de toque se sobrepõem e você tem comportamentos imprevisíveis, especialmente em modais com múltiplas camadas. Para navigation, o React Navigation é o padrão do mercado mas tem uma pegadinha. O Stack Navigator empilha telas e cada tela nova mantém o estado da anterior na memória. Em projetos grandes, isso vaza memória silenciosamente. O workaround é usar unmountOnBlur nas configurações do stack ou implementar cleanup manual nos useEffects das telas que não precisam manter estado.
O maior problema prático que eu encontro hoje em dia é a diferença de comportamento entre iOS e Android em componentes nativos. Text truncamento, cores de input, shadow em buttons — tudo muda. Eu mantenho um arquivo de theme com valores condicionais por plataforma e aplico em todo o projeto. Demora mais no início, mas economiza horas de ajuste fino depois. Se você está começando agora, foque em dominar Flexbox no contexto do RN antes de mexer em anything mais complexo. O resto é detalhe. Layout bem feito desde o início evita refatoração gigante depois. E não subestime o papel do Flipper para debug — ele salva muito tempo comparado a console.log espalhado pelo código.
