Dúvida conceitual Smart/Dumb Components

[rodrigoclp]

Olá Fernando. Curso bom demais. Parabéns pelo trabalho.

Tenho uma dúvida com relação aos métodos de ação de um dumbComponent. Por exemplo: digamos que eu tenha um dumbForm que será carregado em 3 locais diferentes da minha aplicação. Este form possui 3 ações: loadUpdateData, create e update (hipoteticamente falando - não são bem essas as ações). Como eu faço para não reescrever essas handlers 3 vezes?

SmartComponent-1

• dumbForm-1
• anortherDumbComponent-1

SmartComponent-2

• dumbForm-1
• ...

SmartComponent-3

• dumbForm-1
• ...

Todos os dumbComponents devem estar dentro de um smartComponent próprio para ele? Tipo:

• smartForm-1
  • dumbForm-1

• utilizei essa nomenclatura smart e dumb, mas não é assim que utilizo. O dumb component deixo com o nome puro e o smart, insiro um ...Container.js no final.

Agradeço sua ajuda.

Obrigado.

@fdaciuk

[rodrigoclp]

HOC funcionando como uma camada de services? Ou o novo React Hooks resolveria esse compartilhamento de lógica?

[fdaciuk]

Oi @rodrigoclp! Vamos lá:

Como eu faço para não reescrever essas handlers 3 vezes?

Se o seu formulário é exatamente o mesmo, com as mesmas regras para todos os lugares onde você vai usá-lo, e você não precisa compartilhar o estado desse form com componentes externos, então você pode escrever esse form como um Smart Component, sem problemas. Dessa forma você centraliza o estado desse componente nele mesmo :)

Todos os dumbComponents devem estar dentro de um smartComponent próprio para ele?

Não necessariamente. Depende muito do que você vai fazer. Para aplicações menores, normalmente nós temos um único Smart Component, onde teremos os estados globais da aplicação, que são compartilhados com vários componentes, e todos os outros componentes abaixo dele são Dumb. Assim você centraliza e isola o estado.

Mas não há problema algum em chamar um Smart Component dentro de um Dumb Component, por exemplo; como no seu caso dos formulários: se você tiver os estados no app.js, e os componentes abaixo dele forem Dumb, e lá dentro você precisar colocar um Form autocontido, com regras próprias e que não precisam ser compartilhadas, esse Form pode ser Smart sem problema algum :)

HOC funcionando como uma camada de services?

HOC é usado como abstração. Imagine a seguinte situação: você tem uma configuração de temas para sua aplicação, e quer que um componente receba as informações do tema via props, pois componentes são apenas funções puras, não têm estado, então tudo o que for injetado via props é como se passássemos via parâmetro para uma função normal.

Isso facilita isolamento do componente para reuso e testes, por exemplo.

Então, pra injetar os estilos em um componente puro, podemos usar um HOC, que seria uma função que recebe o componente via argumento, e injeta essas props do tema que o componente vai precisar usar. Seria mais ou menos essa a ideia de usar um HOC, explicando bem por cima =)

Ou o novo React Hooks resolveria esse compartilhamento de lógica?

Os Hooks podem servir pra isso também, mas a ideia principal deles ao substituir HOCs é permitir uma melhor visualização da árvore de componentes na hora de debugar. Como HOCs criam sempre um novo componente para injetar props no componente passado via parâmetro, eles acabam criando um ramo a mais na árvore. Já usando Hooks, você vai usar simples variáveis dentro da função, não afetando em nada a estrutura da aplicação :)

---

Bom, foram muitas perguntas, espero que tenha ficado claro. Qualquer coisa, só avisar =)

[rodrigoclp]

Entendido. Obrigado pela atenção.

[fdaciuk]

Qualquer coisa avisa ae =)