Estrutura para grandes projetos e React + Redux

[felisio]

Bom dia a todos,
Tenho pesquisado bastante, perguntado bastante e estudado muito sobre esse assunto e vi que cada um acaba adotando um tipo de arquitetura para a criação de grandes projetos feito e react + redux. Gostaria de saber como vcs constroem e padronizam suas arquiteturas, pensando em grandes projetos com projeção de crescimento tipo um ERP. Obrigado a todos.

[diessica]

Tenho trabalhado com esta estrutura nas aplicações:
https://gist.github.com/ryanflorence/daafb1e3cb8ad740b346

Estou bem satisfeita.

Outros artigos que recomendo:

• http://jaysoo.ca/2016/02/28/organizing-redux-application/
• http://engineering.kapost.com/2016/01/organizing-large-react-applications/

[felisio]

Valeu Diéssica, os dois últimos já li são muitos bons, o primeiro que vc passou, tem sido a arquitetura ate agora mais usada, fiquei meio invocado com essa nomenclatura "screens" mais acho que vou adotar gostei do conceito, obrigado pelas dicas fez a diferença.

[diessica]

O primeiro é o que eu uso, mas aprendi bastante com as duas outras leituras. Pelo o que lembro, o pessoal geralmente divide por stores, actions etc.

A nomenclatura "screens" fez sentido para mim. Mas você precisa pensar na prática:
Assim que você vai desenvolvendo, vai perceber que nem tudo é um componente reaproveitável e "plugável", e, portanto, não poderia ser classificado como tal. Nesse caso, é uma screen. Uma screen é única. São elas que serão o component de uma Route do react-router, por exemplo.

Você pode adaptar a sua aplicação também. Eu, por exemplo, não uso assim:

app
└── screens
    └── App

Uso direto assim:

app
└── App

Também não uso assim:

[...]
Reports
└── index.js

E sim:

[...]
Reports
└── Reports.js

E assim vai, dependendo do projeto. Essas adaptações, obviamente, devem ser devidamente documentadas. :)

[felisio]

Atualmente a arquitetura que desenhei ta bem parecido com essa que vc ta falando

├── app
   ├── core
       └── components
           └── card.js
   ├── Operation
       └── Reports
             └── report.js
             └── reportAction.js
             └── specs
                    └── report-specs.js

Estou dividindo em areas e dentro dessas area crio as features, minha maior dúvida seria só em relação aos components, reducers e etc... comuns a todos, criei a pasta core para fazer como um biblioteca de comuns aonde dentro dele criaria um pasta components e etc... , porem essa nomeclatura "core" usado em projetos com outro paradigma de arquitetura não sei se ficou legal... rsrsrsrsr

[diessica]

[...] minha maior dúvida seria só em relação aos components, reducers e etc... comuns a todos [...]

Nesse caso, você coloca eles em uma pasta shared, localizada em uma posição comum aos que compartilham esses reducers, components...

[felisio]

Diessica da uma olhada no que montei ate agora.... no caso iria criar as pastas screens dentro da area operacional e colocar nesse caso aluno dentro de screens? Obrigado mais uma vez pelos esclarecimentos

[diessica]

Bacana! Pelo o que você mostrou, está tudo ok sim!

Se "aluno" é uma tela (uma página), então você está certo: é uma screen; portanto, deve ficar dentro da pasta screens.

Uma boa rule of thumb é: Os links da navegação nunca vão para componentes, eles vão sempre para telas (screens) – nessas telas sim ficam os componentes, que podem ser cards, breadcrumbs, seções de conteúdo etc.

Só aquele TipoAluno que ficou jogado ali. Ele deve estar em uma das possíveis pastas. Se é uma outra tela, por exemplo, você coloca outra pasta screens. Se é um componente, dentro de components. Enfim, sempre dentro de uma outra pasta que indique seu papel na aplicação.

Percebi que você cometeu esse mesmo erro aqui:

   ├── Operation
       └── Reports

---

Um exemplo da aplicação que estou trabalhando...

"Vendors" (Vendors/Vendors.js) é uma lista de todos vendors. Ao clicar em um deles (você clica no card, que é um componente que fica dentro de Vendors/components), você irá para a tela do detalhe desse vendor (Vendors/screens/Vendor/Vendor.js). É screen dentro de screen.

[bernardodiasc]

Acho interessante (particularmente, acho obrigatório) usar a ideia de container components também, super bem explicado aqui https://gist.github.com/chantastic/fc9e3853464dffdb1e3c

O lance é ter toda a logica e manipulaçao dos dados nos containers, isso seria o código javascript propriamente dito enquanto os componentes de template são exclusivos para a marcaçao (html via jsx). Aproveito para usar .jsx nos componentes de template enquanto uso .js normal em todos os outros arquivos, apenas para facilitar a visualização. Tento não cometer os mesmos erros que muitos sistemas PHP cometem ao permitir escrever bizarramente HTML em arquivos PHP (wordpress, drupal, etc)...

[lagden]

o php tem o twig que faz isso direitinho... é só fazer direito...
esse jsx é muito feio!!!

[bernardodiasc]

jsx esta para twig assim como js esta para php. exatamente isso que o gist fala (com outras palavras) :)

[lagden]

bahhh... eu já tinha sugerido isso long time ago...
acho q o React estava na versão 0.13...
talvez exista ainda a discussão no Slack do frontend Brasil

[bernardodiasc]

existem opções ao JSX pra quem acha feio:

• https://github.com/mlmorg/react-hyperscript
• https://github.com/pugjs/react-jade
• etc...

[diessica]

É importante explicitar que, ao usar JSX, você não está colocando HTML em arquivos JavaScript. Escrevendo JSX, você está escrevendo React elements – não elementos HTML. A sintaxe é somente semelhante ao HTML, simplesmente porque é a linguagem de marcação que usamos.

Se você não gosta de gerar elementos HTML usando JavaScript, que é o que o React abstrai (e várias outras bibliotecas e frameworks também), daí é outro assunto – e não é culpa do JSX.

Enfim, acredito que discussões sobre o JSX enquanto sintaxe não compreendem a essa issue, e sugiro que voltemos ao tópico original.

[lagden]

@diessica jsx é um transpiler like a coffeeScript, ts, etc...
O lance é organizar melhor, ou seja, separar o bloco html em arquivo .htmlx por exemplo! Nada mais...
Sorry about [off]!!

[diessica]

Não há o que organizar, pois não existem blocos de HTML no código de um componente React.

Usar js ou jsx é uma questão de convenção. Desde que o uso da sintaxe JSX esteja devidamente documentado (afinal, JSX não é obrigatório no React), não há nada de errado.

[lagden]

sim, mas o htmlx seria bem mais legal!! hauhau...
o debug seria diferente...

[bernardodiasc]

Um bom uso de Stateless Functional Components, Container Components etc, já resolve o problema de "organizar melhor". =)

Concordo. Trouxe essa definição de containers na issue pois é uma abstração conceitual, já que na prática, por ser tudo Javascript as chances de fazer tudo misturado é garantida pra quem não compreende exatamente o que é um template.

Template é um bloco de código que transforma um bloco de dados em html. O template não computa, não conecta no server, etc. Template (ex: jsx) transforma dados estruturados (ex: json) em marcação de dados (ex: html). Deixar o view e o controller no mesmo arquivo é uma falha na organização, IMHO.

[bernardodiasc]

Nota: templates existem desde 1999. É fácil de entender, mas curiosamente sistemas como Wordpress e Drupal, estão começando a usar no core agora, em 2016... Vai entender...

[lagden]

@bernardodiasc valeu pelo bloco adicional

[felisio]

@diessica cheguei a versão quase final.... rsrsrsr olha ai

[bernardodiasc]

Valeu pelas dicas @diessica, bem maneira essa organizaçao dos arquivos pelas routes. 👍

[diessica]

Opa, esqueci de responder! @felisio eu só não colocaria o reducer em screens. em screens só screen, mais nada. Nem actions, nem reducers, nem action types. Questão de onde pôr o CSS é mais escolha sua, se você acha que é bom ali, beleza. Eu deixo junto com o componente.

@bernardodiasc nada! :)

[bernardodiasc]

Passando pra compartilhar esse artigo https://medium.com/@rajaraodv/the-anatomy-of-a-react-redux-app-759282368c5a, tem a ver com a abstração dos componentes na estrutura Redux.

[felisio]

Fala @diessica, foi mal tu me respondeu eu não vi.... obrigado por responder, realmente ficou difícil com esse conceito de screens porque minha ideia era criar o container completo e desacoplado então se eu fosse criar nesse caso a screen de aluno aonde colocaria meus arquivos redux? se fosse criar fora acabaria tento de criar outra pasta aluno so para o redux, ai ele não fica escalavel.... me explica melhor essa ideia valeu....

[diessica]

Sugiro que você leia com atenção o gist do ryanflorence, incluindo comentários.

[felisio]

@diessica, não entendi de inicio que ideia era colocar os reducers dentro da pasta shared e que meus containers serão os screens..... pelo menos foi o que entendi ate agora

[dbuarque]

Aplicações Escaláveis com React e React Native

Como escalar o desenvolvimento de aplicativos web e mobile de forma eficiente utilizando React e React Native

https://medium.com/getty-blog-brasil/aplicações-escaláveis-com-react-e-react-native-2d337deaf8a1

[JoseCage]

OFF, @felisio que ferramenta usou para os desenhos acima??

Achei interessante.

[bernardodiasc]

@JoseCage tenta esse https://www.npmjs.com/package/tree-cli

[JoseCage]

Opa @bernardodiasc referia-me ao desenho (protótipo/wireframe) não a listagem de diretórios.. Em todo caso, acredito que em caso usarei a ferramenta que me indicou.. 👍