Uma estrutura de pastas que aguenta o React Native crescer

App pequeno tolera qualquer pasta. App com login, listas, push e uns três fluxos de negócio não tolera. A estrutura abaixo é a que eu uso quando o projeto deixa de ser um protótipo.

O que eu evito

• components/ com 80 arquivos soltos
• Tela importando API, estilo e regra de negócio no mesmo arquivo
• Nome de pasta genérico demais (utils, helpers, common) sem dono

Uma base que escala

src/
  app/            # navegação e providers
  screens/        # uma pasta por tela
  components/     # UI reutilizável, sem regra de negócio
  features/       # domínio: treino, exame, pedido
  services/       # HTTP, analytics, push
  hooks/
  theme/
  types/

Cada tela em screens/Home/ concentra o que só ela usa: view, estilos e hooks locais. Se um card da Home passar a aparecer em outro lugar, aí ele sobe para components/ ou para a feature correspondente.

Features vs screens

screens são rotas. features são o assunto.

Exemplo: o fluxo de laudo médico pode ter features/reports/ com API, tipos e um hook useReport. A tela screens/ReportDetails/ só monta a UI e consome esse hook.

Isso evita o clássico: copiar a mesma chamada de API em três telas.

Serviços

services/ fala com o mundo externo. Um arquivo por integração ajuda na hora de mockar teste:

• services/api.ts — cliente HTTP
• services/auth.ts — token e sessão
• services/push.ts — FCM / Klaviyo

A tela não precisa saber se o token veio do Firebase ou de um storage local.

TypeScript no limite certo

Tipo o que cruza fronteira: resposta de API, props públicas, params de rota. Não precisa tipar todo objeto intermediário de um .map.

O React Navigation tem um padrão decente para params. Vale adotar cedo, porque rota sem tipo vira any espalhado.

Quando refatorar

Se você leva mais de um minuto para achar “onde esse botão dispara o request”, a pasta já ficou atrás do app. Ajuste na feature atual, não num rewrite geral.