Front End

7 out, 2016

Estruturando um aplicativo em React.JS

Publicidade

Não podemos negar que hoje a stack de front-end possui uma vasta variedade de frameworks e bibliotecas. E nessa variedade, uma biblioteca vem se destacando no mercado: a React.js. Neste artigo, vou cobrir uma estrutura escalável e de fácil manutenibilidade para você desenvolver o seu próximo aplicativo.

1. Processo de build

Hoje, se você usa uma biblioteca como React.js, provavelmente também já utiliza um processo de build para otimizar o tempo de desenvolvimento. O único ponto que quero ressaltar para seu processo de build é que, para essa estrutura funcionar bem, você deve usar uma configuração para que o seu build reconheça a sua pasta raiz como uma possível pasta de módulos do npm.

Por exemplo, se você tentar importar o arquivo components/my-component, ele primeiro vai buscar dentro de node_modules, e, em seguida, vai buscar dentro da sua pasta raiz, que, no caso, teria uma pasta chamada componentes com um arquivo chamado my-component.js.

Aqui estão algumas opções dependendo do processo de build que você usa:

webpack: http://bit.ly/28QV7rc

grunt/gulp com browserify: http://bit.ly/28NnSRM

2. Estrutura de pastas

Vamos começar com uma estrutura de pastas um pouco diferente:

  • screens
  • shared
  • actions
  • stores
  • index.js

2.1. Screens

Pense na screen como os componentes com mais responsabilidade no seu app, geralmente são componentes que estão ligados à store da sua aplicação de alguma maneira. A pasta screens da raiz da sua aplicação também pode conter os componentes de suas rotas, por exemplo:

screens

  • dashboard
  • profile
  • notifications

Agora vamos ver mais a fundo o que temos dentro da pasta dashboard.

dashboard

  • screens
  • componentes
  • index.js

Dependendo da complexidade do seu app, você pode ter componentes que se conectam com a store que estão aninhados. Nesses casos, você criaria outra pasta de screens, com a mesma estrutura mostrada acima.

Um exemplo visual de como seria a tela de dashboard, separada em screens:

ms01

A área vermelha seria a lista de informações da dashboard, e a azul seria uma barra lateral possivelmente ligada a ações que influenciam a lista. A pasta components é onde os seus componentes sem muita responsabilidades ficam. Estes só podem ser usados pela screen em que eles estiverem (veremos como compartilhá-los mais à frente).

O arquivo index.js é a implementação do seu componente em si.

2.2. Shared

Dentro da pasta shared, teremos tudo que for compartilhado por vários pontos da sua aplicação. Um exemplo da pasta de shared:

shared

  • – utils
  • – contants
  • – components

Em utils, podemos ter vários tipos de utilitários que usamos em nossa aplicação. Um excelente exemplo para o uso da pasta utils seria uma autenticação de login, que seria importado nos componentes em que o usuário precisa estar autenticado para usar.

Na pasta constants, podemos colocar as ações de sua lib de flux ou as urls das suas rotas – isso pode variar muito de acordo com o seu projeto. Já na pasta components ficam os componentes que compartilhamos em toda a nossa aplicação. São geralmente componentes mais genéricos.

Agora, vamos ver como seria usar esses arquivos dentro de uma screen.

import Select from ‘shared/componentes/select’;

import dashboardConstants from ‘shared/constants/dashboard’;

import auth from ‘shared/utils/auth’;

Note que estamos importando o módulo da mesma maneira que importaríamos algo instalado via NPM (como explicado no primeiro tópico).

2.3. Actions

A pasta actions contém todas as ações da sua aplicação, e elas podem ser separadas baseadas nas rotas que você usa, ou até mesmo por responsabilidades que suas ações terão. Um exemplo:

actions

  • – dashboard.js
  • – profile.js
  • – notifications.js

2.4. Stores

Semelhante às ações, as stores podem ser fragmentadas como achar melhor. Uma maneira de organizá-las seria por responsabilidades do seu app. Exemplo:

stores

  • – products.js
  • – form.js
  • – notifications.js

2.5. index.js

O index.js é o ponto de entrada de nossa aplicação. Ele é o arquivo no qual devemos colocar todas as implementações genéricas que vão ser usadas pela sua aplicação inteira, como a configuração das rotas do nosso app, o ponto de entrada da biblioteca de Flux que estivermos utilizando, usar o utilitário de autenticação para filtrar usuários logados, e assim vai.

3. Testes

Não vou cobrir como fazer testes, acho que esse assunto está além deste artigo, mas como organizar os seus testes é algo que se encaixa muito bem aqui.

Hoje, a maioria das bibliotecas de teste, ao serem executadas, busca recursivamente todos os arquivos dentro de uma pasta específica, ou que sigam um mesmo padrão (auth.test.js, por exemplo), e os executa automaticamente. Essas configurações podem ser feitas no seu processo de build.

Tendo isso em mente, podemos deixar todos os testes no mesmo diretório do arquivo que está sendo testado.

app

  • – shared
  • — utils
  • — __tests__
  • —- auth.js
  • — auth.js

Isso se aplica a qualquer lugar em que um teste precise ser feito. Se tivermos testes dentro de componentes, ficaria algo semelhante a isto:

app

  • – shared
  • — componentes
  • — select
  • —- __tests__
  • —– index.js
  • —- index.js

4. Nomeação

Você deve ter notado que o nome index.js foi usado com certa frequência. Gosto de pensar que nossa aplicação deve ser a mais genérica possível, e nada mais genérico que um arquivo chamado index.js. Todos os componentes e screens são organizados por pastas que têm um nome declarativo, como dashboard. Dentro dessa pasta, o arquivo de implementação sempre se chamará index.js, caso contrário, o arquivo pode ter o nome do módulo.

5. Conclusão

Falamos sobre diversas abordagens neste artigo, mas vamos rever aqui os pontos mais vantajosos de usar essa estrutura:

Organização

Nessa estrutura, fica muito claro onde cada arquivo deve ficar. Tem um componente que se conecta com a store? Ele é uma screen. Tem um módulo genérico que vai ser compartilhado por vários lugares? Ele vai dentro de shared. É muito simples de aplicar, basta seguir algumas regras.

Manutenção

É muito simples achar arquivos nessa estrutura. Você pode descobrir onde está o arquivo de um componente só de olhar para o seu app no browser. Nessa estrutura de pastas com uma nomeação declarativa, que é bem intuitiva para desenvolvedores novos, achar componentes e testes se torna algo banal.

Nenhuma solução é uma bala de prata. Se essa estrutura não se encaixar no seu app, modifique-a! Crie algo novo e compartilhe com a comunidade, novas ideias são sempre bem-vindas.

Veja um exemplo funcional dessa estrutura no link: https://github.com/mauriciosoares/react-screens-boilerplate.

***

Artigo publicado originalmente na Revista iMasters #19