Estrutura de um aplicativo React Native

Primeiramente, é importante dizer que não existe exatamente uma forma correta ou uma errada de se organizar os arquivos de um aplicativo React Native. Na teoria o desenvolvedor pode montar o seu app da forma que quiser e até colocar todos os arquivos em uma pasta só se ele quiser e o app ainda vai funcionar corretamente.

Mas, enquanto nós ainda somos humanos, nós precisamos de um mínimo de organização nos dados para podermos nos encontrar no meio daquele monte de arquivos que compõem um aplicativo React Native.

Existem inúmeras formas de se organizar os arquivos do seu app, mas eu estarei mostrando uma forma que eu vi recentemente e pareceu bastante simples:

Assets

A pasta “Assets” tem o intuito de guardar todos os assets usados no aplicativo, ou seja, todas os arquivos “visuais” por assim dizer, significando imagens, ícones e as fontes utilizadas nos textos do aplicativo. Dentro da pasta “Assets” se divide os arquivos em outras duas pastas: “Fontes” para as fontes diferentes utilizadas e “Imagens” para as imagens e ícones.

Components

Na pasta “Components” se cria arquivos .js para características que geralmente serão repetidas em várias partes diferentes do aplicativo. Em outras palavras, nessa pasta se cria arquivos que funcionarão como “carimbos”, por exemplo: Várias páginas têm um mesmo botão “voltar” que sempre tem a mesma forma, cor e funcionalidade, portanto, para poupar espaço e processamento, não precisamos criar o mesmo botão várias vezes com as mesma características e funcionalidades. Em vez disso se cria um componente que pode se chamar de “BotãoVoltar.js” como na imagem acima e com isso é só chamar o componente “BotãoVoltar.js” toda vez que for colocar aquele botão em alguma página.

Contexts

De forma simples, Context API é um “local” seguro que você vai armazenar dados temporários de uma aplicação, faz-se isso porque, alem de ser seguro, não é necessário fazer varias requisições desses mesmo dados ganhando performance por não precisar fazer requests. Um exemplo é o uso de “tokens” para a identificação de cada usuário em um processo de login.

Pages

Essa parte tem duas formas bastante usadas no geral, a forma 1 (representada na figura acima) consiste em colocar uma pasta para cada página (para este exemplo “Menu” e “Login”) e dentro de cada pasta de página colocar juntos o arquivo index.js daquela página e o arquivo styles.js na mesma pasta para facilitar o trabalho com aquela página específica.

A forma 2 (figura acima) é outra bastante utilizada e que pode ter também uma pequena variação. Nesse modelo, se põe os arquivos “index.js” de cada página dentro de uma pasta com o nome da página correspondente dentro da pasta “pages” enquanto os arquivos “styles.js” ficam em uma pasta separada chamada “styles” que guarda outras pastas com o nome das páginas e dentro delas os arquivos “styles.js” referente àquela página se encontra. Uma variação bastante encontrada é a colocação dos arquivos “index.js” diretamente dentro da pasta “pages” e os “styles.js” direto na pasta “styles” e só se diferencia um do outro por colocar nomes explicativos como “menuIndex.js” e “menuStyles.js”.

Services

A pasta “services” serve para fazer a ligação entre o front end e a API, é nela que os arquivos que fazem as trocas de dados ficam, de forma resumida.

Stack

Do inglês literalmente “pilha”, a pasta Stack guarda todos os arquivos que configuram as chamadas “pilhas” de páginas. Um Stack é, resumidamente, uma agrupamento de páginas que têm algum tipo de relação, como a tela de uma publicação feita que fica por cima de uma tela “home” quando se clica em uma publicação feita para vê-la. Esse amontoado de telas é uma “pilha”, ou “stack”, de telas relacionadas, e para sua criação, faz-se um arquivo e põe-se o mesmo dentro dessa pasta “stack”.

Por fim, esse é um modo de se organizar os arquivos de um app React Native. Lembrando que esse não é o único e muito menos o “mais apropriado” pois no fim depende muito de que tipo de app será desenvolvido e também do gosto do desenvolvedor.