Solucionado (ver solução)
Solucionado
(ver solução)
2
respostas

Questões sobre reusabilidade

Boa tarde, tudo bem?

Sei que há uma grande vantagem em relação a abstrair as responsabilidades e utilizar a DI a favor de um código desacoplado e estou totalmente de acordo com a separação da interface e serviços, assim como ocorre no back-end; entre repositorios e a implementação dos métodos de fato. Porém, para levantamento, gostaria de questionar alguns pontos

  1. Conforme link do repositório abaixo, agora teremos useFecth[nome_do_recurso] customizado para cada recurso: Categories, Products, etc, porém, algo que começa a se repetir, são as definições de isLoading, error e a própria lógica idêntica do método fetchCategories e fetchProducts em cada hook individual. Essa repeticção não poderia ser evitado, fazendo com que os hooks especializados, utilizassem como base ainda o useFecth genérico? ou alguma outra abordagem?
  2. Por não estar sendo definido instâncias de classes, mas sim sendo definido em funções, não há o risco de eu chamar o useFetchProducts em mais de um local e gerar problemas de performance por não adotar alguma prática como o Singleton, correto? Mas em relação a funções que foi o formato implementado, não há nenhum risco desse tipo da forma implementada, correto?
  3. Caso eu desejar implementar demais métodos REST, como POST, PUT, DELETE, bastaria seguir os passos abaixo, correto?
    • adicionar o contrato em cada interface ( ex: IProductService ),
    • implementar o método em cada useFetch individual,
    • adicionar o método em cada service ( ex: ProductsService )
    • adicionar o método na interface IHttp

https://github.com/alura-cursos/4105-use-dev-commerce-app/compare/aula-04...aula-05

Obrigado

Felipe D.R

2 respostas
solução!

Oi Felipe. Tudo bem?

Vamos lá, vou tentar esclarecer suas dúvidas:

  1. Repetição nos Hooks Customizados: Você está certo em notar a repetição de lógica nos hooks customizados, como isLoading, error, e a lógica de fetch. Uma abordagem comum para evitar essa repetição é criar um hook genérico, como useFetch, que encapsula essa lógica comum. Depois, os hooks específicos, como useFetchCategories ou useFetchProducts, podem usar esse hook genérico internamente, passando apenas as diferenças necessárias, como a URL do recurso. Isso ajuda a manter o código DRY (Don't Repeat Yourself) e facilita a manutenção.

  2. Problemas de Performance e Singleton: Como os hooks são funções e não instâncias de classe, não há risco de criação desnecessária de objetos como ocorreria em um Singleton. No entanto, é sempre importante monitorar renderizações desnecessárias, garantindo que os hooks dependam apenas dos estados e efeitos necessários.

  3. Implementação de Métodos REST: Sim, a abordagem que você descreveu está correta. Ao adicionar métodos REST adicionais, você precisaria:

    • Adicionar o contrato na interface correspondente, como IProductService.
    • Implementar o método no hook customizado específico, se necessário.
    • Adicionar o método no serviço correspondente, como ProductsService.
    • Incluir o método na interface IHttp, se ela for responsável por definir os métodos HTTP disponíveis.

    Essa abordagem mantém a consistência e a separação de responsabilidades, facilitando a manutenção e a expansão do código.

Espero ter ajudado!

Siga firme nos seus estudos e conte com o fórum sempre que precisar!

Abraços :)

Caso este post tenha lhe ajudado, por favor, marcar como solucionado

Perfeito, obrigado Mike