Cara, sensacional, eu tenho pensado do pq raios ninguém fala sobre os patterns de UI no RN e tu foi o primeiro a trazer isso, eu tava pensando em aplicar exatamente dessa forma num projeto, fico feliz que mais alguém pensou nisso, assim eu N pareço louco de mudar totalmente a forma como trabalhamos com React
eu achei q eu manjava de react native, depois q comecei a trabalhar com flutter q fui aprendendo que existem os padrões de projetos. agora voltando pro react eu sempre me perguntei pq ngm estrutuvava ou falava sobre os padrão no react. que bom que vc fez video pra usar como refêrencia vlw.
Top em man isso q estava precisando. Sozinho em outro projeto e vivo tendo que testar tudo quando faço alguma mudança. Assim vai ficar bem mais fácil pensando até em usar o detox só UI
Estou trabalhando em uma aplicação que inicialmente era mais simples e usava MVC, depois de um tempo a complexidade aumentou muito e tô pensando se seria interessante o MVVM
Nos seus teste você fica verificando o snapshot, um exemplo é que o botão deve estar disabled={true} caso loading seja true. Você consegue reproduzir isso mockando ali, isso eu entendi, porém, para verificar se ficou disabled={true} de verdade você só consegue olhando o snapshot por conta própria. Não acho muito bom isso, até pq tira o fator de ser teste "automatizado". Faz sentido isso ? Se fizer, tem alguma coisa que podemos fazer a mais para fazer essas verificações de forma automática ? Além disso, parabéns pelo vídeo, eu estaa interessado em utilizar NVVM para RN faz um tempo e ninguem publica conteudo disso a uns 6 meses atrás, parabéns pela iniciativa. Show dmais.
Na vdd, você não precisa abrir o arquivo e verificar manualmente. Se o snapshot falhar o teste já quebra indicando que houve mudança. No vídeo eu fiquei usando a flag -u que refaz todos os snapshots, mas se vc não usar ela e mudar algo mostrará um erro para ti. Sobre automatizar você pode rodar esse teste no github actions por exemplo só instalar as deps e rodar yarn test no seu CI
@@Catapulta-club No caso isso esta indicando que teve diferença mas não necessariamente um erro, e tb do jeito que mostrou, deixa implicito que deve rodar ao menos uma vez certo e deixar o snapshot correto gravado para que no furuto quando "rodar" sem a flag -u apresente diferença. Não parece muito legal a ideia de que o mesmo teste dependa de um "resultado" antigo dele mesmo.
@@alecsandersouzafarias8334 sim, esse tipo de teste pode sim variar. Ele geralmente é usado para verificar se o design tá correto. No repositório além do teste de snapshot eu fiz os testes unitários caso a caso. Por exemplo, no unitário eu vejo se tem os inputs, mas o de snapshot pode verificar para mim se a cor não mudou. Dar uma olhada no repo
sem usar o teste de snapshot, você poderia garantir de outras formas primeira selecionando o botao e depois fazendo um expect se ele tem a propriedade disabled const button = screen.getByText(/salvar/i); expect(button).toBeDisabled(); ou expect(button ).toHaveAttribute('disabled');
Sensacional a explicação, porém fiquei com uma dúvida, em quais locais da aplicação eu utilizaria os métodos que tratam do ciclo de vida dos componentes? Caso sejam aplicados nas views, não estaríamos acrescentando regra de negócio nas views?
vou te dar alguns exemplos, se vc usar o react hook form, vc colocaria na view ou no controller para validar os inputs? eu colocaria na view pq se os inputs n estao corretos o ideal é a view lidar com isso e so chamar a regra de negocio passando os inputs validados. Ou se vc tem um state para ativar um modal, onde vc colocaria? @igor ramon
não seria muito mais fácil e intuitivo fazer teste de integração do fluxo inteiro ao invés de unitário, isto é, preencher email, preencher senha, clicar no botão submit e verificar que onSubmit foi chamado com valor correto, ou não foi chamado se estiver faltando algo?
![CLEAN ARCHITECTURE + MVVM [PARTE 1] - ENTENDENDO A TEORIA](http://i.ytimg.com/vi/5_rLFMQmYFg/mqdefault.jpg)
Cara, sensacional, eu tenho pensado do pq raios ninguém fala sobre os patterns de UI no RN e tu foi o primeiro a trazer isso, eu tava pensando em aplicar exatamente dessa forma num projeto, fico feliz que mais alguém pensou nisso, assim eu N pareço louco de mudar totalmente a forma como trabalhamos com React
Ismael aqui, sim hehe
eu achei q eu manjava de react native, depois q comecei a trabalhar com flutter q fui aprendendo que existem os padrões de projetos. agora voltando pro react eu sempre me perguntei pq ngm estrutuvava ou falava sobre os padrão no react. que bom que vc fez video pra usar como refêrencia vlw.
Top em man isso q estava precisando. Sozinho em outro projeto e vivo tendo que testar tudo quando faço alguma mudança. Assim vai ficar bem mais fácil pensando até em usar o detox só UI
Muito bom, parabéns
vídeo incrível!
Onde ficaria o useeffect ? Dentro da view ou viewModel ?
Useeffect fica na parte que sincroniza com o sistema externo.
Muito bom meu amigo!
Conteúdo super daora!
Muito bem explicado! Parabéns!
Boaaa
Estou trabalhando em uma aplicação que inicialmente era mais simples e usava MVC, depois de um tempo a complexidade aumentou muito e tô pensando se seria interessante o MVVM
Muito bom. Parabéns Ismagel
🧩
Nos seus teste você fica verificando o snapshot, um exemplo é que o botão deve estar disabled={true} caso loading seja true. Você consegue reproduzir isso mockando ali, isso eu entendi, porém, para verificar se ficou disabled={true} de verdade você só consegue olhando o snapshot por conta própria. Não acho muito bom isso, até pq tira o fator de ser teste "automatizado". Faz sentido isso ? Se fizer, tem alguma coisa que podemos fazer a mais para fazer essas verificações de forma automática ?
Além disso, parabéns pelo vídeo, eu estaa interessado em utilizar NVVM para RN faz um tempo e ninguem publica conteudo disso a uns 6 meses atrás, parabéns pela iniciativa. Show dmais.
Na vdd, você não precisa abrir o arquivo e verificar manualmente. Se o snapshot falhar o teste já quebra indicando que houve mudança. No vídeo eu fiquei usando a flag -u que refaz todos os snapshots, mas se vc não usar ela e mudar algo mostrará um erro para ti. Sobre automatizar você pode rodar esse teste no github actions por exemplo só instalar as deps e rodar yarn test no seu CI
@@Catapulta-club No caso isso esta indicando que teve diferença mas não necessariamente um erro, e tb do jeito que mostrou, deixa implicito que deve rodar ao menos uma vez certo e deixar o snapshot correto gravado para que no furuto quando "rodar" sem a flag -u apresente diferença. Não parece muito legal a ideia de que o mesmo teste dependa de um "resultado" antigo dele mesmo.
@@alecsandersouzafarias8334 sim, esse tipo de teste pode sim variar. Ele geralmente é usado para verificar se o design tá correto. No repositório além do teste de snapshot eu fiz os testes unitários caso a caso. Por exemplo, no unitário eu vejo se tem os inputs, mas o de snapshot pode verificar para mim se a cor não mudou. Dar uma olhada no repo
sem usar o teste de snapshot, você poderia garantir de outras formas primeira selecionando o botao e depois fazendo um expect se ele tem a propriedade disabled
const button = screen.getByText(/salvar/i);
expect(button).toBeDisabled();
ou
expect(button ).toHaveAttribute('disabled');
@@doug8590 isso funciona pra react-native ? Achei que esses de getByText era só pra web
Sensacional a explicação, porém fiquei com uma dúvida, em quais locais da aplicação eu utilizaria os métodos que tratam do ciclo de vida dos componentes?
Caso sejam aplicados nas views, não estaríamos acrescentando regra de negócio nas views?
vou te dar alguns exemplos, se vc usar o react hook form, vc colocaria na view ou no controller para validar os inputs? eu colocaria na view pq se os inputs n estao corretos o ideal é a view lidar com isso e so chamar a regra de negocio passando os inputs validados. Ou se vc tem um state para ativar um modal, onde vc colocaria? @igor ramon
muito legal, mas poderia falar quais comandos você utilizou pra iniciar o projeto?
reactnative.dev/docs/environment-setup?os=windows&platform=android
não seria muito mais fácil e intuitivo fazer teste de integração do fluxo inteiro ao invés de unitário, isto é, preencher email, preencher senha, clicar no botão submit e verificar que onSubmit foi chamado com valor correto, ou não foi chamado se estiver faltando algo?
Com certeza