Raphael, pesquisei muito e cheguei no seu vídeo, que pra mim, foi o melhor conteúdo disparado. Compreensão muito simples e explicação sem enrolação. Muito obrigado por compartilhar o seu conhecimento. Te desejo sucesso!
gostei do video, bem simples. Mas qual a necessidade de criar fns pra alterar estado se o proprio setEmail e setPassowrd ja sao sao fn pra isso? nao seria mais fácil passar logo os sets pelas props?
Poderia sim. Mas eu tenho esse costume de fazer funções que altera estados por 2 motivos. 1 - normalizar e padronizar as coisas 2 - caso um dia eu precise aplicar alguma máscara ou algum lógica a mais no estado ficaria mais fácil.
Já que sua model (useLoginModel) é um hook, pq você decidiu passar eles (handleSubmit, email, etc..) para a camada de view via props, ao invés de usar o hook useLoginModel como um hook de fato?
Boa!! Na vdd poderia ser feito com hook também. Não teria problema nenhum. Mas a minha intenção via props era deixar o mínimo de lógica possível na camada de view. Se usasse o hook direto lá eu teria que extrair tudo do useLogin. Com as pros eu n preciso disso e a camada de view fica mais "limpa"
Cara ficou sensacional seu vídeo!!! Mas tenho uma dúvida, no caso a camada que você chamou de model não seria a view-model?? Onde você manipula os dados que vem da model ( API / banco) e deixa eles disponíveis para a View utilizar.
Opa, obrigado pelo comentário! Entendo a confusão, pois realmente há algumas variações na terminologia em diferentes artigos. No padrão MVVM (Model-View-ViewModel), as camadas são definidas da seguinte forma: Model: Responsável pela lógica de negócios e dados da aplicação, acessando e manipulando dados de fontes como APIs ou bancos de dados. View: A camada de apresentação, que exibe os dados ao usuário e contém a interface do usuário. ViewModel: Atua como intermediária entre a View e o Model, manipulando os dados do Model e disponibilizando-os para a View. Também contém a lógica de apresentação e comandos acionados pela View. A ViewModel é, portanto, a camada que une a lógica de negócios (Model) com a camada de apresentação (View). Talvez a confusão venha do uso do termo “Model” em outros padrões de design
Eu costumo criar uma camada de serviço onde eu coloco toda a parte do crud, é uma boa prática? para cada crud que eu faço eu crio uma camada para cada.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
![React Native melhora layout e Nova Arquitetura [Cortes Compilado]](/img/n.gif)
Ótima explicação, resumiu de forma super clara 👏🏻
Ae Brotherr!!! Parabéns pelo conteúdo!
Satisfação vc por aqui, manoo!!
Muito simples e muito funcional... Uma arquitetura que estava com dificuldades de entender, entendi em 6 minutos
Parabéns pelo conteúdo!
Sua abordagem direta e prática facilitou bastante a compreensão.
*O audio está muito baixa
Raphael, pesquisei muito e cheguei no seu vídeo, que pra mim, foi o melhor conteúdo disparado. Compreensão muito simples e explicação sem enrolação. Muito obrigado por compartilhar o seu conhecimento. Te desejo sucesso!
gostei do video, bem simples. Mas qual a necessidade de criar fns pra alterar estado se o proprio setEmail e setPassowrd ja sao sao fn pra isso? nao seria mais fácil passar logo os sets pelas props?
Poderia sim. Mas eu tenho esse costume de fazer funções que altera estados por 2 motivos.
1 - normalizar e padronizar as coisas
2 - caso um dia eu precise aplicar alguma máscara ou algum lógica a mais no estado ficaria mais fácil.
Já que sua model (useLoginModel) é um hook, pq você decidiu passar eles (handleSubmit, email, etc..) para a camada de view via props, ao invés de usar o hook useLoginModel como um hook de fato?
Boa!! Na vdd poderia ser feito com hook também. Não teria problema nenhum. Mas a minha intenção via props era deixar o mínimo de lógica possível na camada de view. Se usasse o hook direto lá eu teria que extrair tudo do useLogin. Com as pros eu n preciso disso e a camada de view fica mais "limpa"
Cara ficou sensacional seu vídeo!!! Mas tenho uma dúvida, no caso a camada que você chamou de model não seria a view-model?? Onde você manipula os dados que vem da model ( API / banco) e deixa eles disponíveis para a View utilizar.
Opa, obrigado pelo comentário! Entendo a confusão, pois realmente há algumas variações na terminologia em diferentes artigos. No padrão MVVM (Model-View-ViewModel), as camadas são definidas da seguinte forma:
Model: Responsável pela lógica de negócios e dados da aplicação, acessando e manipulando dados de fontes como APIs ou bancos de dados.
View: A camada de apresentação, que exibe os dados ao usuário e contém a interface do usuário.
ViewModel: Atua como intermediária entre a View e o Model, manipulando os dados do Model e disponibilizando-os para a View. Também contém a lógica de apresentação e comandos acionados pela View.
A ViewModel é, portanto, a camada que une a lógica de negócios (Model) com a camada de apresentação (View). Talvez a confusão venha do uso do termo “Model” em outros padrões de design
@@raphaelcorreadev entendo! Muito obrigado pela resposta! Valeu demais mano!
Eu costumo criar uma camada de serviço onde eu coloco toda a parte do crud, é uma boa prática? para cada crud que eu faço eu crio uma camada para cada.
É sim!! Mas vc poderia cria uma forma de reaproveitar seu código.
god