Esse conteúdo só é possível graças aos Membros do Canal Flutterando!! A Todos os membros muuuuuito obrigado Devs por todo o apoio!! Link do Clean Dart: github.com/Flutterando/Clean-Dart
Cara, eu até acho bacana, acho que tem muita coisa que podemos aprender e usar em nossos projetos mas não vejo como ser produtivo em um projeto usando tudo isso.. Apesar, parabéns pelo canal, muito bacana ver esse crescimento. Detalhe, qual plugin está usando pra criar os construtores no minuto 17:30?
@@FlutterandoTV Uma dǘvida. Esses models não seria colocado, por exemplo, uma pasta core ou commns ? pois colocando em um módulo, ele poderia ser usado em outro módulo. Então não iria repetir o código ? ou a abordagem seria usar esse model mesmo sendo de outro módulo ? quais das 3 alternativas vocês usam? eu vejo melhor a primeira.
Em vez de estender da classe ResultSearch o correto não seria implementar ela? Isso de herdar e ter de reescrever os mesmos campos da classe pai é um pouco estranho.
Fiz dessa forma e meus dados veio todos nulos, depois que coloquei o super() ele começou a passar os dados, mas mesmo assim ficava nulo. Graças ao meu brother Bwof falou que eu teria que tirar os atributos na Model para que o construtor super passe os valores, ai sim deu certo
Jacob, estou acompanhando a série, sou muito a favor de fazer tudo pensando la na frente, mas to achando que é coisa de mais pra um projeto. Atualmente estou utilizando aquela arquitetura que você comenta no começo do primeiro video (MVVM, repositories, etc) e até agora está tranquilo na parte de manutenção (as vezes preciso voltar atras de algumas coisas) e adição de novas funcionalidades. Também utilizo o conceito de interfaces para criação de services. Acredito que somente na dor eu talvez iria para este conceito de clean arch, assim como somente na dor fui atrás de uma arquitetura nova (MVVM, repositories, etc). Mas não posso deixar de dizer que o conteúdo é excelente e é sempre bom aprender coisas novas. Por mais que estou achando que a quantidade de coisas está gigantesca, estou gostando do conteúdo e como comentei, assim como eu, talvez muitas pessoas também só tomarão a decisão de ir para esta metodologia se a dor for muito grande. Ainda não tive problemas com o MVVM e se um dia irei adotar o clean arch, só o tempo dirá. Continue trazendo conteúdos desse nível pra comunidade, seu conhecimento para nós é de grande importância.
Boa noite no novo flutter umas coisas mudaram ai eu queria entender melhor eu fiz a classe ResultSearch e também fiz a ResultSearchModel, ai dentro do meu SearchDataSource na função ficou assim Future getSearch(String? searchText); porém na classe SearchRepositoryImplementation quando eu vou fazer o return Right(result) ele da este erro "The argument type 'List?' can't be assigned to the parameter type 'List?'." No caso ele diz que o retorno do meu datasource e diferente do retorno esperado da minha função só que ai que ta ele reclama mesmo o ResultSearchModel sendo uma classe extendida do ResultSearch
é importante verificar a quantidade de chamadas feitas no mock e mais importante ainda é reiniciar as interações antes de todos os testes. Isso reduz a quantidade de erros de verificação quando se tem condições que podem causar chamadas repetidas a algum serviço.
Respeito a ideia mas acho que esses padrões estilo DDD fazem pouco sentido pra apps frontend/mobile. Acho o apelo bem maior no caso de aplicações backend já que os limites dos domínios internos ao negócio ficam bem definidos e fica muito mais fácil modificar o código. No caso do frontend me parece overengineering. Normalmente (90% dos aplicativos) a UI só fica responsável por passar informação do frontend pro backend via uma interface web. Não faz sentido abstrair services, repositories, entities, etc. Um padrão no estilo "UI + gerência de estados + interface web" me parece que já resolve bem o problema. A maior vantagem dos frameworks com UIs declarativas (React, Flutter, SwiftUI) é que eles simplificam MUITO o desenvolvimento de aplicações nesse estilo onde o problema é renderizar a UI a partir do estado do app. É um problema completamente diferente de apps backend que definem regras de negócio.
No result_search_model.dart, quando mandei gerar o JSON no lugar do static ele criou como factory. deste jeito: factory ResultSearchModel.fromMap(Map map factory ResultSearchModel.fromJson(String source) => ResultSearchModel.fromMap(json.decode(source)); pode deixar assim, ou mudo para static?
![Diggy Graves - Red Vineyard [Official Lyric Video]](http://i.ytimg.com/vi/8Ro085T0mnQ/mqdefault.jpg)
Esse conteúdo só é possível graças aos Membros do Canal Flutterando!!
A Todos os membros muuuuuito obrigado Devs por todo o apoio!!
Link do Clean Dart:
github.com/Flutterando/Clean-Dart
As semanas do Flutter estão cada vez melhores! Muito obrigado pelo conteúdo!
Excelente aula! Mas tenho uma dúvida, essa seria uma abordagem utilizando TDD?
Muito bom. Excelente conteúdo como sempre, parabéns!
Bemm legal. Obrigado por compartilhar
parabéns...foi demais!!
Cara, eu até acho bacana, acho que tem muita coisa que podemos aprender e usar em nossos projetos mas não vejo como ser produtivo em um projeto usando tudo isso.. Apesar, parabéns pelo canal, muito bacana ver esse crescimento.
Detalhe, qual plugin está usando pra criar os construtores no minuto 17:30?
Gabriel Braga Miranda essa produtividade vc só vera na manutenção ;)
Dart Data Code Generate
@@FlutterandoTV Uma dǘvida. Esses models não seria colocado, por exemplo, uma pasta core ou commns ? pois colocando em um módulo, ele poderia ser usado em outro módulo. Então não iria repetir o código ? ou a abordagem seria usar esse model mesmo sendo de outro módulo ?
quais das 3 alternativas vocês usam? eu vejo melhor a primeira.
A camada de infra vai ser utilizada apenas quando houver um tratamento dos dados vindo de uma fonte externa? Como ele seria no caso de uma câmera?
Em vez de estender da classe ResultSearch o correto não seria implementar ela? Isso de herdar e ter de reescrever os mesmos campos da classe pai é um pouco estranho.
Vitor Fernandes pode ser tb. (Mas n sei se iria ficar óbvio para todo mundo se fizesse assim
Fiz dessa forma e meus dados veio todos nulos, depois que coloquei o super() ele começou a passar os dados, mas mesmo assim ficava nulo. Graças ao meu brother Bwof falou que eu teria que tirar os atributos na Model para que o construtor super passe os valores, ai sim deu certo
Jacob, estou acompanhando a série, sou muito a favor de fazer tudo pensando la na frente, mas to achando que é coisa de mais pra um projeto. Atualmente estou utilizando aquela arquitetura que você comenta no começo do primeiro video (MVVM, repositories, etc) e até agora está tranquilo na parte de manutenção (as vezes preciso voltar atras de algumas coisas) e adição de novas funcionalidades. Também utilizo o conceito de interfaces para criação de services. Acredito que somente na dor eu talvez iria para este conceito de clean arch, assim como somente na dor fui atrás de uma arquitetura nova (MVVM, repositories, etc). Mas não posso deixar de dizer que o conteúdo é excelente e é sempre bom aprender coisas novas. Por mais que estou achando que a quantidade de coisas está gigantesca, estou gostando do conteúdo e como comentei, assim como eu, talvez muitas pessoas também só tomarão a decisão de ir para esta metodologia se a dor for muito grande. Ainda não tive problemas com o MVVM e se um dia irei adotar o clean arch, só o tempo dirá.
Continue trazendo conteúdos desse nível pra comunidade, seu conhecimento para nós é de grande importância.
Boa noite no novo flutter umas coisas mudaram ai eu queria entender melhor eu fiz a classe ResultSearch e também fiz a ResultSearchModel, ai dentro do meu SearchDataSource na função ficou assim Future getSearch(String? searchText); porém na classe SearchRepositoryImplementation quando eu vou fazer o return Right(result) ele da este erro "The argument type 'List?' can't be assigned to the parameter type 'List?'."
No caso ele diz que o retorno do meu datasource e diferente do retorno esperado da minha função só que ai que ta ele reclama mesmo o ResultSearchModel sendo uma classe extendida do ResultSearch
é importante verificar a quantidade de chamadas feitas no mock e mais importante ainda é reiniciar as interações antes de todos os testes.
Isso reduz a quantidade de erros de verificação quando se tem condições que podem causar chamadas repetidas a algum serviço.
Gustavo Rodrigues um passo de cada vez... setUp em breve
Qual tema usa Jacob?
Qual o nome da extensão que está usando para gerar o Json Serialization no minuto 6:00
Dart Code generator
Ótimo!
Respeito a ideia mas acho que esses padrões estilo DDD fazem pouco sentido pra apps frontend/mobile. Acho o apelo bem maior no caso de aplicações backend já que os limites dos domínios internos ao negócio ficam bem definidos e fica muito mais fácil modificar o código.
No caso do frontend me parece overengineering. Normalmente (90% dos aplicativos) a UI só fica responsável por passar informação do frontend pro backend via uma interface web. Não faz sentido abstrair services, repositories, entities, etc. Um padrão no estilo "UI + gerência de estados + interface web" me parece que já resolve bem o problema. A maior vantagem dos frameworks com UIs declarativas (React, Flutter, SwiftUI) é que eles simplificam MUITO o desenvolvimento de aplicações nesse estilo onde o problema é renderizar a UI a partir do estado do app. É um problema completamente diferente de apps backend que definem regras de negócio.
phrsngx concordo com vc, mas tb temos serviços como Firebase e Hasura que são BaaS, aí vai precisar ter O domínio no FrontEnd.
@@FlutterandoTV Verdade! Acho que pode fazer sentido em apps como esses, onde as regras de negócio precisam estar definidas no próprio app.
Primeiro!
No result_search_model.dart, quando mandei gerar o JSON no lugar do static ele criou como factory. deste jeito:
factory ResultSearchModel.fromMap(Map map
factory ResultSearchModel.fromJson(String source) => ResultSearchModel.fromMap(json.decode(source));
pode deixar assim, ou mudo para static?
isso foi mais ou menos as 6:20min