Criando uma estrutura escalável para sua aplicação

Introdução

Muitas vezes quando você inicia o desenvolvimento de uma aplicação, não há um planejamento de como nomear e organizar os arquivos de uma forma que sua aplicação seja escalável. Depois que ela cresce sem organização, fica díficil outra pessoa além de você mexer no código e aí cada um nomeia de um jeito(PARE!!!).

Vou me basear em uma aplicação usando React Native com as principais libs: Redux , React Navigation , Redux Saga , etc. Isso vai servir para qualquer aplicação que a ideia seja desacoplar o máximo de coisa possível.

Árvore de arquivos

- assets
- src
    - components
    - features
    - navigation
        - stacks
    - screens
    - services
        - api
    - shared
        - constants
        - validations
        - utils
    - state
    - App.js
- index.js
- .babelrc

Essa separação de arquivos é toda baseada em Features, que nada mais é que toda novidade que você deseja criar na sua aplicação

Estrutura de pastas

src/components

É semelhante ao UI, com componentes que serão comuns em mais de uma tela do sistema. A ideia é de que não tenhamos mais uma pasta como essa na aplicação, visto que depois você pode criar separado uma UI, compartilhando seus componentes em qualquer sistema que você tenha.

src/features

É onde armazenamos todos as features do sistema, com seus respectivos components e containers.

• Components : O component da feature irá usar os components ou algum específico
• Containers : No caso, como usamos Redux , aqui estão os disparos das actions, propriedades da store, etc.

src/navigation

Aqui temos o Router.js, do qual funciona semelhante a um React Router. Na pasta stacks está separado por features cada stack de rotas de navegação.

src/screens

Pasta que contém as telas do sistema. Em cada tela, podemos chamar os componentes(UI) comuns que estão na pasta components tanto quanto as features que ficam na pasta features, fazendo com que não seja misturado nenhum estado das features.

Uma observação é que conforme a necessidade nos faça criar novas telas, seria melhor separar as screens por features, criando uma pasta com nome da feature.

src/services

É onde colocamos serviços com integrações com aplicações de terceiros, client_para a API, etc. Na pasta api, temos os _clients da API, com o arquivo api.js que contém a base do client e depois os clients nomeados por feature. Aqui caso você use um serviço, como o Firebase, por exemplo, você pode adicionar as configurações dele em uma pasta firebase.

src/shared

Aqui é onde compartilhamos qualquer coisa(com exceção dos componentes) que seja comum em mais de um lugar na aplicação.

src/state

Pasta que contém a estrutura de estados da aplicação, separados por feature. Cada pasta da feature irá conter essencialmente:

• actions: Arquivo que contém as actions creators disparadas no container da feature
• reducer: Arquivo que contém o reducer da feature
• sagas: Arquivo que contém as sagas(side-effects das actions) da feature
• types: Arquivo que contém as definições de tipo das actions disparadas no container da feature
• schema: Arquivo que contém schema para normalizar a estrutura dos dados recebidos pelo client da API ( OBS: NEM SEMPRE É NECESSÁRIO)

Não precisa ser uma estrutura idêntica a essa, mas com esse post você pode se basear para criar sua própria estrutura escalável.

Tentei passar no post a importância de uma estrutura como essa para que sua aplicação não fique bagunçada a ponto de ninguém querer se juntar a sua ideia, por bagunça de código.