Na aula vimos a opção de deixar a regra de negócios no container e no componente basicamente a renderização. E aí chegou nessa parte do hooks, a duvida é se o hook anula a necessidade do container e vice e versa ou ainda tem sentido por algum motivo de manter o container mesmo tendo o hook, pf.
Olá Sara! Tudo bem?
A sua dúvida sobre a relação entre hooks e containers é bem interessante. Vamos lá:
Os hooks e os containers servem a propósitos diferentes, mas podem complementar-se dependendo da arquitetura da sua aplicação.
Hooks: Eles são usados para encapsular e reutilizar lógica de estado e efeitos colaterais. Quando você cria um hook, está basicamente abstraindo uma lógica que pode ser reutilizada em diferentes componentes. Isso ajuda a manter o código limpo e modular.
Containers: No padrão Container-Presenter, o container é responsável por buscar dados e lidar com a lógica de negócios, enquanto o presenter cuida apenas da renderização. O container pode usar hooks para gerenciar o estado e os efeitos colaterais.
Somente Hooks: Se a lógica de negócios for simples e específica de um componente, você pode encapsular essa lógica em um hook e usá-lo diretamente no componente.
Containers com Hooks: Se você tem uma lógica de negócios mais complexa ou que precisa ser compartilhada entre vários componentes, pode ser útil manter o padrão Container-Presenter, usando hooks dentro do container para gerenciar o estado e os efeitos colaterais. Isso mantém a separação de responsabilidades clara.
Ou seja, os hooks não anulam a necessidade de containers. Eles são ferramentas que podem ser usadas juntas para criar uma arquitetura mais limpa e sustentável.
Espero ter ajudado. Conte com nosso apoio :)
Abraços e bons estudos!