Responsabilidade de cada elemento

[taisesoares]

Ola @luiguild ouvi seu podcast e li seu arquivo na medium. Tenho uma dúvida quanto a responsabilidade de cada elemento do atomic design, segundo o livro, a PAGE possui a responsabilidade de passar as informações para os demais. Porém não fica estranho um componente, page passar objetos, funções para o Template, e esse Template passar para organisms e etc?
Exemplo real, tenho um formulário de cadastro usuário, o arquivo que monta o formulário está dentro de organisms, que precisa receber determinadas informações, tais como: Nome do usuário, endereço. Eu pego esse organisms e passo para o template, já desenhando como vai ser a estrutura da minha pagina. E então pego esse template e passo para a PAGE. Na page, eu vou enviar os dados do usuário, e do endereço como props para o template e do template para o organismo? Isso estaria correto?

[luiguild]

Oi @taisesoares! Que legal sua pergunta! Fico muito feliz em saber que o material continua sendo relevante até hoje! De ante mão, já te digo que em breve eu terei novidades sobre isso. :)

Sobre sua pergunta, preciso começar dizendo que com o passar dos anos, de tanto aplicar a metodologia em todos os meus projetos, minha percepção é de que quando estamos criando um projeto com um Atomic Design System utilizando Vue, React, Svelte ou qualquer outro framework do mercado, nós devemos excluir a página do fluxo.

Isso mesmo, A página não precisa existir. Nosso trabalho termina no template e ele deve ser o entry-point do seu projeto. A partir dele todo fluxo de conteúdo se inicia e todo fluxo de interação do usuário termina.

Anexado aqui na sua issue, vou deixar um fluxograma que criei visando facilitar a vida ainda mais de quem procura material sobre o assunto. Eu que elaborei esse material e acho que ele está certo porque até já vi plágios dele por aí hahahaha

Boa sorte com o projeto!

[taisesoares]

Olá @luiguild eu pensei em algo assim desenvolvendo aqui, mas mantive a page. Estou usando a contextAPI do React, então mantive algo tipo:

Dessa forma que pensei, o único que pode fazer POST, DELETE ou PUT para a rota é Organisms. Molecules e Template fazem apenas GET. E a contextAPI fica no Page chamando o template que vai ter todas as informações.

Minha maior preocupação era ficar algo bagunçado, mas analisando agora, até mesmo com sua imagem, cheguei em algo que realmente parece ser útil. Onde tudo fica englobado do Organisms.

Uma ultima dúvida, estou usando o material UI como design system, criei um arquivo denominado "design-system" e dentro dele tenho as chamadas do material (o que seria meu Atoms). Também tenho um arquivo chamado core, que nele tem os dados de Molecules e Organisms, como por exemplo (Drawers, Menus, Modal etc..).

Quando crio um novo modulo na minha aplicação, dentro dele tenho os components que tbm são atoms, molecules e organisms. É de má pratica, caso eu precise de algo do core, como um Drawers, que está dentro de organisms, eu chamar no meu modulo ele dentro de molecules?

[luiguild]

Obrigado por compartilhar de forma mais detalhada seu approach @taisesoares, curti a imagem que você fez!

Não conheço seu caso de uso completo e nem o tamanho da sua aplicação então fica um pouco complexo de opinar sobre um aspecto global.

Na minha opinião, se te ajudar em algo, eu não deixaria nenhum componente que não seja template ou ourganismo fazer requisições. Diria mais até, essa divisão de responsabilidade se é de GET ou POST não deve, nunca, ser responsabilidade de um componente visual. Sei que com um dos pontos da ContextAPI é a não-necessidade de uma máquina global de estados, mas ainda sim, eu continuo vendo esse tipo de necessidade pra evitar esse tipo de dúvida relacionada com a responsabilidade do componente.

Pra mim, você deveria ter bósons que sabem fazer as requisições, neles estão encapsuladas todas as suas necessidades que não são visuais. Lembre-se sempre que um componente precisa, necessariamente, manter a interoperabilidade entre componentes, se você tem um componente de "alto nível" como um organismo, template ou até mesmo uma página (como no seu caso) eles não devem nunca serem capazes de "travarem" a aplicação por completo caso seja necessário trocar algum deles. Eu indicaria fortemente que você retirasse a responsabilidade de um componente visual, de fazer requisições.

Como eu coloquei na minha imagem, esse é um modelo validado por várias empresas em vários casos diferentes, acredito que moléculas, átomos, quarks e bósons devem ser totalmente stateless, recebendo dados exclusivamente por props e não por conteúdos externos que eles mesmos possam adquirir.

Pra mim, num flow ideal, o template é o entry point, ele chama as requisições necessárias para a construção do campo visual da página, já que ele é o componente menos reusável do seu projeto, ele chama todos os outros e vai passando por props todos os conteúdos, porém, ao mesmo tempo, como a palavra template sugere, ele precisa ser reutilizável ainda em outros contextos, por isso, um organismo pode fazer requisições isoladas também, independente se são de escrita ou de leitura.

Sobre seu último ponto de ter arquivos que chamam multiplos elementos do material, se pra você e seu time estiver ok dessa forma, vai fundo, porém eu diria pra você isolar as chamadas de cada um dos elementos em arquivos menores, é melhor você ter milhares de arquivos menores do que você ter um "domínio" enorme abraçando todo mundo num arquivo só.

E sobre chamar alguém dentro de alguém, lembre-se sempre das responsabilidades e dos "tamanhos" dos personagens. Se você estiver precisando chamar um organismo dentro de uma molécula, então na real você tá tentando fazer um template e não uma molécula. Mantenha sempre as abstrações escaláveis para que no futuro você não tenha comunicações "cruzadas" de elementos maiores dentro de elementos menores.