Ótima essa iniciativa do Flutter, e Excelente o seu vídeo, também acho que um vídeo implementando esse exemplo com explicações pontuais, seria muito bem-vindo.
Finalmente 🥰 Era o que eu espera, quando comecei a usar flutter, essa foi uma das minhas maiores duvidas. Agora sera mais fácil ser iniciante em flutter.
Os vídeos do Diego são sempre ótimos de acompanhar, os únicos de Flutter que assisto sem sair nos primeiros minutos/segundos. Eu sempre criei meus apps de forma simples, sem adicionar muitas dependências ou seguindo sempre padrões mais conhecidos e testados.
Sempre trazendo novidades, achei bem completo essa doc, colocando um projeto pronto ficou melhor ainda para entender na pratica como tudo ta funcionando.Vlw pela novidade
Ótimo vídeo. O que mais gostei nessa doc (apesar de não ser a coisa mais importante) foi a parte de deixarem bem claro a parte da camada de regra de negocio como opcional. Já trabalhei em muitos projetos que pessoas adicionavam essa camada sem necessidade alguma, apenas para falar que estavam usando uma arquitetura limpa, por exemplo. E o mais engraçado é que o proprio livro comenta de não usar todas aquelas recomendações ao pé da letra. E acho que nesse ponto essa doc foi bem feliz: explicar o porque de cada coisa, trazer um contexto e você poder adaptar isso para sua realidade. No fim, acredito que o mais importante continua sendo o Dev entender os principios arquiteturais e como usa-los na pratica sem ficar reeinventando ou complicando o que pode ser simples.
Sempre me senti "forçado" a usar o clean arch / clean dart por líderes técnicos de projetos e, com poucos meses de projeto, já percebia a dificuldade de novos integrantes do time a aderir rapidamente a arquitetura, muitos arquivos..., camadas desnecessárias, etc. Mas desde o ponto que tive a liberdade de opinar, tomar decisões e ajudar na montagem de uma arquitetura, sempre fui pro lado mais "simplificado". Fico feliz em saber que tava indo pro caminho certo, semelhante ao recomendado pela Google, e isso é uma espécie de validação. Muito bom!! Tenho usado bastante os Records e o "novo" switch via "sealed class". Acho que esses recursos deram mais flexibilidade.
Sim, muitos projetos definiram arquiteturas extremamente complexas para tentar contornar a questão de manutenção e escalabilidade, mas faltou olhar a carga cognitiva e curva de aprendizado dos devs... Felizmente isso está melhorando aos poucos... Acho que vou começar a trazer conteúdos sobre arquitetura, pois o vídeo reforçou isso
Já faço algo parecido faz tempo kkkk: Pastas principais Core/Data/Shared e Features/nome_feature/{views, controllers (manipula a tela), components, services (conversa com data)}. Tem funcionado bem.
Top demais professor, sempre foi a minha dúvida o que usar como arquitetura. Como sugestão poderia pegar um projeto do canal e remodelar ele para esse modelo sugerido por eles pf.
Muito bom! Seria otimo criar um app de exemplo passa a passo para entender melhor a arch, seria bom abordar algo sobre módulos tambem, separar o codigo em micro apps, nao vi muitos comentários sobre isso
isso veio em ótima hora, estou iniciando um projeto com melos e queria quebrar as camadas em pacotes separados, adaptar pra essa arquitetura vai ser bem produtivo
Muito top! Legal que eu já faço isso de maneira rudimentar com os FutureBuilder da vida, que um vai gerenciando o outro em uma árvore. Até hoje nunca vi algo que supere a minha tratativa em todos os sentidos, não só em implementação e desempenho. Vale ressaltar a manutenção também, uma vez decida a arquitetura, não tem mais volta.
Comecei num projeto com MVC, usavamos o Modular e com o tempo eu fui removendo o Modular e seguindo o conceito do clean arch. Tínhamos uma arch simples com controllers e nenhum usecase. Umas das melhores arquiteturas que usei no Flutter. Usecase aqui e ali, bloc com no mínimo 3 states. É complexidade para mais de metro.
ótimo vídeo, professor! gostei bastante da nova área de arquitetura da documentação, mvvm é uma das arquiteturas que mais gostei de aprender por implementar bem os princípios de separação de responsabilidades e sem o famoso over-engineering. super recomendo!
Com certeza, MVVM para a UI é bem consolidado no mobile. Foi uma recomendação olhando para o ecossistema e, se precisar, pode substituir a implementação para outras estratégias como Bloc, Signals, Riverpod, etc.
Achei excelente esse posicionamento do time de engenharia do flutter, era necessário esse posicionamento sobre direcionamento. Usar Change ou Value Notifier, com MVVM, provider e go router. Simples e de facil entendimento, sem necessidade de build_runner
Gostei desse commands. Vou testá-lo. E ver como posso implementar o riverpod nessa arquitetura. Mas de fato, é uma grande evolução. Flutter sempre nos surpreendendo!
é um guideline muuuito parecido com arquitetura mvvm proposta pela google para usar no Android, seja em view system ou jetpack compose. Só muda a questão dos commands
Será que algum dia o time do flutter vai conseguir criar algo que seja tão simples de usar tipo igual ao conceito do GetX mas de forma nativa. Seria muito bom.
Por favor mestre.. monta um projeto com essa arquitetura. Se puder aplicar em um projeto anterior, tipo aqueles de times de futebol ou das cripto moedas para comparação, é melhor ainda 😃
Olá! Vou tentar me expressar melhor: considerando uma tela que exibe dados de contato (nome, e-mail, número, etc.), como manter esses dados visíveis na tela principal enquanto abre um diálogo com outros dados relacionados atividade do contato? A abordagem correta seria criar um estado ActivityState (estado do bloco de atividade) dentro da classe ContactState? E, no builder, usar algo como if (state.data.ActivityState != null) para exibir o diálogo?
Não entendi bem a dúvida em si. Pelo que entendi são telas diferentes, com VM diferentes que se conectam no mesmo Repository (relacionados ao contato)... É isso?
eu achei do caralho essa recomendação, só existia dessa qualidade no android, e foi onde eu tomei tudo como referência para os meus projetos em Web também. Mas em tempos de AI, não iria tomar conta de tudo? Por que investir em documentação de arquitetura logo agora? heheheheh
Meu truta, seu canal é fantástico e eu particularmente gostou muito da sua didática. Vejo pelos comentários que você é professor (faculdade?). Gostaria de ter um feedback construtivo: **faça pelo menos 6 meses de intercâmbio para melhorar esse inglês 🙏🏾!** Seus videos são muito bons, mas te ouvir pronunciando os termos em inglês “command”, “listenable” e afins chega dói na alma. E como professor me preocupa o fato de alunos se espelharem em você e assumir que a pronuncia deles estará boa já que o professor deles fala assim. Espero que receba esse feedback como algo construtivo e não deixe de fazer vídeos tão bons quanto esse para nossa comunidade ❤
A pronúncia do inglês dá pra resolver sim, mas o mais importante é trazer conteúdo que, muitas vezes, não foi noticiado nem fora do Brasil (como neste caso). Provavelmente fui o primeiro a trazer este conteúdo, justamente para manter a comunidade atualizada e engajada (e veja o alcance que isso tomou). Faço isso gratuitamente e pago do meu bolso todo o custo que o canal gera, sempre na maior dificuldade. Agora, o UA-cam está começando a dublar o conteúdo... então sugiro assistir dublado para uma experiência mais requintada do inglês (mesmo sendo por IA). Venho formando alunos há mais de 10 anos e nunca ouvi que falar "command" com a pronúncia incorreta atrapalhou algum deles... De toda forma obrigado pelo feedback, buscarei melhorar
Arquitetura é de projeto para projeto, o exemplo do flutter é bem simples… agora para projetos que usam metodo channel, ou sao whitelabel ou algo especifico, vao acabar tendo varias camadas faltantes. Os desenvolvedores tem que entender que patterns são peças de lego que não necessariamente precisam ser utilizadas em todos os projetos, em alguns utilizasse mais uns e em outros usa outros. A preocupação do desenvolvedor deveria saber se adaptar a padrões e aprender a aprender os padrões que foram construídos no projeto que ele vai atuar e seguir eles (e/ou propor mudanças).
Uma duvida professor os canais Flutter Tips e Flutter na Prática estão com vídeos postados a mais de 2 anos, o conteúdo desses canais ainda é funcional com as novas versões do Flutter ? Abraços
Sim, pouca coisa mudou ... se algo mudou, a propria documentação irá sugerir ou já fiz vídeo complementar ;) O Flutter na Prática devo atualizar em 2025 (possivelmente)
nao entendo uma coisa, pela visao do prof voce é contra camada de domain em apps "simples", mas recomenda o command o usecase é um command ue a entity é o que o viewmodel representa porem isolado no contexto de regra de negocio, sem logica de acesso a outras camadas envolvida
MVC - A view é controlada diretamente pelo Controller em casos específico usa até BuidContext nele. MVP - A view deixa de ser dependente do controller e acessa diretamente os dados por meio de um contrato/interface implementadas no Presenter. MVVM - A view continua independente mas reage aos dados por data binding/observer/listener.
Certo, então colocando em código o MVC seria um StatefulWidget e o MVVM no caso não existe no Flutter pelo fato da ausência de um data binding, certo? Ou seja independente do padrão MV{x} o que sempre importou foi separar a lógica da view e usar um tipo de reatividade.
@@eronplay1015 Não, os widgets fazem parte da view. E esse data binding existe em qualquer lugar, só implementar o padrão observer e escutar mudanças. No Flutter, o que se usa mais é isso, ChangeNotifier, Streams e etc... A razão sim foi sempre separar a lógica e o padrão que se consegue tal proesa é o MVVM porque ao invés de depender de algo externo a view fica só escutando por essa reatividade que seria o binding.
@@mthsenaCorreto parcialmente, porque nenhum widget “escuta” um listener diretamente, entendo a abstração e o conceito que a equipe do Flutter trouxe, mas não concordo com o padrão ser um MVVM, no Flutter teríamos algo novo para os “escutáveis”, eu diria que temos o BLoC para Streams e uma incógnita para os Notifiers.
Isso explica porque o povo prefere React Native, é uma confusão terrível esses padrões do Flutter, está cada vez mais complexo esse negócio, ao invés de facilitar criam milhares de conceitos e não se tem consenso em qual usar.
Comentário de programador fraco que só sabe JavaScript. Flutter não é melhor que React Native, é muuuito melhor. Mas se você não está disposto a aprender uma nova linguagem, fica limitado ao que sabe usar.
Que da hora ver o Flutter oficialmente recomendando vários dos conceitos que eu sempre achei mais simples e fáceis de dar manutenção. Ótimo vídeo.
Pessoal usem react native
Muito bom! Professor, se puder organizar um vídeo implementando os conceitos ficaria muito bom! Abraços...
sério? Está tudo na documentação e lá mesmo tem um passo a passo e você vem pedir um vídeo?
?? Pensei que aqui era o YT, uma plataforma utilizada para postagem de vídeos, mas aparentemente os fiscais tão querendo tirar essa funcionalidade...
@@nero1375 E isso é ruim pra quem? Deixa de ser chato! Faça o vídeo, professor! Vai ganhar views e ainda vai ajudar os alunos! Abs!
@@DouglasViniciusRodriguesSobrin não é nem esse o ponto bicho
@@nero1375 Muitas pessoas têm preguiça de estudar a documentação
Muito Bom professor, um ótimo vídeo seria implementando a nova arquitetura na prática com um projetinho de exemplo!
Ótima essa iniciativa do Flutter, e Excelente o seu vídeo, também acho que um vídeo implementando esse exemplo com explicações pontuais, seria muito bem-vindo.
Finalmente 🥰
Era o que eu espera, quando comecei a usar flutter, essa foi uma das minhas maiores duvidas.
Agora sera mais fácil ser iniciante em flutter.
Pode fazer um vídeo aplicando essa estrutura na prática?
ótimo vídeo Diego!! parabéns pela clareza. Ansioso pelo vídeo criando do 0 um aplicativo com essas novas definições
Os vídeos do Diego são sempre ótimos de acompanhar, os únicos de Flutter que assisto sem sair nos primeiros minutos/segundos.
Eu sempre criei meus apps de forma simples, sem adicionar muitas dependências ou seguindo sempre padrões mais conhecidos e testados.
Obrigado pelo apoio!
Sempre trazendo novidades, achei bem completo essa doc, colocando um projeto pronto ficou melhor ainda para entender na pratica como tudo ta funcionando.Vlw pela novidade
Obrigado! Ainda tem bastante coisa pra complementar, mas é um ótimo ponto de partida.
Muito Bom Diego Antunes, trazendo sempre conteúdo com excelência.
Ótimo vídeo. O que mais gostei nessa doc (apesar de não ser a coisa mais importante) foi a parte de deixarem bem claro a parte da camada de regra de negocio como opcional. Já trabalhei em muitos projetos que pessoas adicionavam essa camada sem necessidade alguma, apenas para falar que estavam usando uma arquitetura limpa, por exemplo. E o mais engraçado é que o proprio livro comenta de não usar todas aquelas recomendações ao pé da letra. E acho que nesse ponto essa doc foi bem feliz: explicar o porque de cada coisa, trazer um contexto e você poder adaptar isso para sua realidade.
No fim, acredito que o mais importante continua sendo o Dev entender os principios arquiteturais e como usa-los na pratica sem ficar reeinventando ou complicando o que pode ser simples.
Sim, nada é bala de prata... Mas conhecer uma recomendação base é bem importante mesmo como ponto de partida para a área.
Show de bola. Tenho um app publicado e ele está com MVVM, porém com seu vídeo falando dessas práticas já notei alguns ajustes a fazer. Obrigado.
Obrigado pela cobertura excelente e divisão de impressões. Botando o compass App aqui para rodar e ver os padrões de composição e testes 🙏
Conteúdo showw! Muito bom, professor
Sempre me senti "forçado" a usar o clean arch / clean dart por líderes técnicos de projetos e, com poucos meses de projeto, já percebia a dificuldade de novos integrantes do time a aderir rapidamente a arquitetura, muitos arquivos..., camadas desnecessárias, etc.
Mas desde o ponto que tive a liberdade de opinar, tomar decisões e ajudar na montagem de uma arquitetura, sempre fui pro lado mais "simplificado". Fico feliz em saber que tava indo pro caminho certo, semelhante ao recomendado pela Google, e isso é uma espécie de validação. Muito bom!!
Tenho usado bastante os Records e o "novo" switch via "sealed class". Acho que esses recursos deram mais flexibilidade.
Sim, muitos projetos definiram arquiteturas extremamente complexas para tentar contornar a questão de manutenção e escalabilidade, mas faltou olhar a carga cognitiva e curva de aprendizado dos devs... Felizmente isso está melhorando aos poucos... Acho que vou começar a trazer conteúdos sobre arquitetura, pois o vídeo reforçou isso
Muiiiiiiiiiiiiiiitooooooooooooooo legal, amei, sempre fui por esse caminho, agora ficou oficial melhorou!!!
Já faço algo parecido faz tempo kkkk: Pastas principais Core/Data/Shared e Features/nome_feature/{views, controllers (manipula a tela), components, services (conversa com data)}. Tem funcionado bem.
Ótimo! Esta semana comecei um novo projeto para um cliente e decidi usar MVVM porque o cliente pediu que fosse escalável
Excelente! E não é algo definitivo, se necessário você pode evoluir sua arquitetura
Gostei do assunto... como iniciante, acho importante!
agora simmmm eu to vendo um tech madura e para long term support
E agora vamos esperar os anúncios do dia 17.
Faz o vídeo explicando a arquitetura na prática!
Seria Interessante um video implementando estes conceitos, otimo video 😊
Top demais professor, sempre foi a minha dúvida o que usar como arquitetura. Como sugestão poderia pegar um projeto do canal e remodelar ele para esse modelo sugerido por eles pf.
Com certeza! Estou planejando muita coisa nova para 2025
Muito bom! Seria otimo criar um app de exemplo passa a passo para entender melhor a arch, seria bom abordar algo sobre módulos tambem, separar o codigo em micro apps, nao vi muitos comentários sobre isso
isso veio em ótima hora, estou iniciando um projeto com melos e queria quebrar as camadas em pacotes separados, adaptar pra essa arquitetura vai ser bem produtivo
Excelente vídeo, professor!
Muito top! Legal que eu já faço isso de maneira rudimentar com os FutureBuilder da vida, que um vai gerenciando o outro em uma árvore. Até hoje nunca vi algo que supere a minha tratativa em todos os sentidos, não só em implementação e desempenho. Vale ressaltar a manutenção também, uma vez decida a arquitetura, não tem mais volta.
Excelentes explicações
Muiro interesse e muito bem explicado pelo professor. 👏👏👏
Comecei num projeto com MVC, usavamos o Modular e com o tempo eu fui removendo o Modular e seguindo o conceito do clean arch.
Tínhamos uma arch simples com controllers e nenhum usecase. Umas das melhores arquiteturas que usei no Flutter.
Usecase aqui e ali, bloc com no mínimo 3 states. É complexidade para mais de metro.
ótimo vídeo, professor! gostei bastante da nova área de arquitetura da documentação, mvvm é uma das arquiteturas que mais gostei de aprender por implementar bem os princípios de separação de responsabilidades e sem o famoso over-engineering. super recomendo!
Com certeza, MVVM para a UI é bem consolidado no mobile. Foi uma recomendação olhando para o ecossistema e, se precisar, pode substituir a implementação para outras estratégias como Bloc, Signals, Riverpod, etc.
Essa documentação fez muito sentido, é algo que sinto muita dor nos over engineer
Achei excelente esse posicionamento do time de engenharia do flutter, era necessário esse posicionamento sobre direcionamento. Usar Change ou Value Notifier, com MVVM, provider e go router. Simples e de facil entendimento, sem necessidade de build_runner
como identificar regras simples ... ou complexas... tem alguns exemplos?.. ajudaria nós os iniciantes....
Gostei desse commands. Vou testá-lo. E ver como posso implementar o riverpod nessa arquitetura. Mas de fato, é uma grande evolução. Flutter sempre nos surpreendendo!
Acredito que você irá trocar os Comandos por Providers do Riverpod (é uma primeira ideia)
Qua saudades dos seus vídeos professor
Obrigado!! Planejando coisas novas para 2025!
@@drantunes se for um curso, estarei na primeira turma!
Na minha opinião, dois motivo para iniciar app com MVVM, aplicativo já realmente grande na largada, white label ou para servir de portfólio e estudo.
Arquitetura é a maior dúvida de todo programador porque nenhum curso ensina na prática
é um guideline muuuito parecido com arquitetura mvvm proposta pela google para usar no Android, seja em view system ou jetpack compose. Só muda a questão dos commands
Ótimo vídeo.
Uma dúvida que tenho, não se usa mais o getX? Não vejo ninguém citar mais essa lib.
Não...
@@drantunes Cuidado, não diga isso abertamente, se não já aparece alguns GetLovers para encher teu saco. 😂😂😂
Será que algum dia o time do flutter vai conseguir criar algo que seja tão simples de usar tipo igual ao conceito do GetX mas de forma nativa. Seria muito bom.
MVVM esta OK.,gostaria de um exemplo para um projeto maior com varias regras de negocio, como ficaria.
Dá uma olhada no Wonderous (não é bem essa arquitetura, mas é bem parecida)
Por favor mestre.. monta um projeto com essa arquitetura. Se puder aplicar em um projeto anterior, tipo aqueles de times de futebol ou das cripto moedas para comparação, é melhor ainda 😃
Agora sim, gostei da nova section
Eu tenho uma opinião sobre, mas vou deixar pro próximo ano.
vou aproveitar a morte do Flutter em paz...
Nunca saberao oq eu disse
@@rafaelfarias1951 mas eu num falei nada
Fala agora, pq o flutter vai acabar esse ano
Até dezembro a gente fala
@@FlutterandoTV Tá bom kk
Olá! Vou tentar me expressar melhor: considerando uma tela que exibe dados de contato (nome, e-mail, número, etc.), como manter esses dados visíveis na tela principal enquanto abre um diálogo com outros dados relacionados atividade do contato? A abordagem correta seria criar um estado ActivityState (estado do bloco de atividade) dentro da classe ContactState? E, no builder, usar algo como if (state.data.ActivityState != null) para exibir o diálogo?
Não entendi bem a dúvida em si. Pelo que entendi são telas diferentes, com VM diferentes que se conectam no mesmo Repository (relacionados ao contato)... É isso?
Ficou ótimo a documentação. Se tivesse isso quando comecei teria sido muito mais fácil
eu achei do caralho essa recomendação, só existia dessa qualidade no android, e foi onde eu tomei tudo como referência para os meus projetos em Web também. Mas em tempos de AI, não iria tomar conta de tudo? Por que investir em documentação de arquitetura logo agora? heheheheh
Prefiro continuar com meu clean arch mesmo rsrsrs mas é legal eles sugerirem alguma arquitetura.
Muito bacana!
Acho que foram bastante coerentes e deixaram alguns pontos opcionais.
Sim, não podem ser tão fechados, senão o hate é enorme
Finalmente! Ponto pra google.
Meu truta, seu canal é fantástico e eu particularmente gostou muito da sua didática. Vejo pelos comentários que você é professor (faculdade?). Gostaria de ter um feedback construtivo: **faça pelo menos 6 meses de intercâmbio para melhorar esse inglês 🙏🏾!**
Seus videos são muito bons, mas te ouvir pronunciando os termos em inglês “command”, “listenable” e afins chega dói na alma. E como professor me preocupa o fato de alunos se espelharem em você e assumir que a pronuncia deles estará boa já que o professor deles fala assim.
Espero que receba esse feedback como algo construtivo e não deixe de fazer vídeos tão bons quanto esse para nossa comunidade ❤
A pronúncia do inglês dá pra resolver sim, mas o mais importante é trazer conteúdo que, muitas vezes, não foi noticiado nem fora do Brasil (como neste caso). Provavelmente fui o primeiro a trazer este conteúdo, justamente para manter a comunidade atualizada e engajada (e veja o alcance que isso tomou). Faço isso gratuitamente e pago do meu bolso todo o custo que o canal gera, sempre na maior dificuldade. Agora, o UA-cam está começando a dublar o conteúdo... então sugiro assistir dublado para uma experiência mais requintada do inglês (mesmo sendo por IA). Venho formando alunos há mais de 10 anos e nunca ouvi que falar "command" com a pronúncia incorreta atrapalhou algum deles... De toda forma obrigado pelo feedback, buscarei melhorar
Arquitetura é de projeto para projeto, o exemplo do flutter é bem simples… agora para projetos que usam metodo channel, ou sao whitelabel ou algo especifico, vao acabar tendo varias camadas faltantes.
Os desenvolvedores tem que entender que patterns são peças de lego que não necessariamente precisam ser utilizadas em todos os projetos, em alguns utilizasse mais uns e em outros usa outros.
A preocupação do desenvolvedor deveria saber se adaptar a padrões e aprender a aprender os padrões que foram construídos no projeto que ele vai atuar e seguir eles (e/ou propor mudanças).
logo agora que o flutter tá morrendo? kkkk brincadeira. show de bola!!!
Microsoft também usa bastante mvvm em suas tecnologias
Uma duvida professor os canais Flutter Tips e Flutter na Prática estão com vídeos postados a mais de 2 anos, o conteúdo desses canais ainda é funcional com as novas versões do Flutter ? Abraços
Sim, pouca coisa mudou ... se algo mudou, a propria documentação irá sugerir ou já fiz vídeo complementar ;)
O Flutter na Prática devo atualizar em 2025 (possivelmente)
nao entendo uma coisa, pela visao do prof voce é contra camada de domain em apps "simples", mas recomenda o command
o usecase é um command ue
a entity é o que o viewmodel representa porem isolado no contexto de regra de negocio, sem logica de acesso a outras camadas envolvida
Faz um app com certa complexidade para sedimentar o entendimento.
Ok, mas no Flutter qual é a diferença do MVVM para o MVC e MVP além do nome do arquivo? 🤔
MVC - A view é controlada diretamente pelo Controller em casos específico usa até BuidContext nele.
MVP - A view deixa de ser dependente do controller e acessa diretamente os dados por meio de um contrato/interface implementadas no Presenter.
MVVM - A view continua independente mas reage aos dados por data binding/observer/listener.
O pessoal costuma misturar um pouco de tudo no Flutter, mas o recomendado sempre foi o MVVM, e agora está oficialmente declarado.
Certo, então colocando em código o MVC seria um StatefulWidget e o MVVM no caso não existe no Flutter pelo fato da ausência de um data binding, certo? Ou seja independente do padrão MV{x} o que sempre importou foi separar a lógica da view e usar um tipo de reatividade.
@@eronplay1015 Não, os widgets fazem parte da view. E esse data binding existe em qualquer lugar, só implementar o padrão observer e escutar mudanças. No Flutter, o que se usa mais é isso, ChangeNotifier, Streams e etc...
A razão sim foi sempre separar a lógica e o padrão que se consegue tal proesa é o MVVM porque ao invés de depender de algo externo a view fica só escutando por essa reatividade que seria o binding.
@@mthsenaCorreto parcialmente, porque nenhum widget “escuta” um listener diretamente, entendo a abstração e o conceito que a equipe do Flutter trouxe, mas não concordo com o padrão ser um MVVM, no Flutter teríamos algo novo para os “escutáveis”, eu diria que temos o BLoC para Streams e uma incógnita para os Notifiers.
Professor o flutter fez um fork recentemente, devemos nos preocupar?
Por hora zero preocupação. Fiz um vídeo sobre isso, dá uma olhada. Qualquer atualização irei trazer aqui ;)
Mobx + Qlevar Router mandou abraço
já era hora!
Sempre fez muito sentido usar mvvm... Enfim, a arquitetura natural ao flutter foi recomendada
Aeeeeee finalmenteeeee
Gostei...menos é mais...
Falou tudo!
Não uso nada disso, nem classes eu uso e sou contra null safety.
Todas essas recomendações, nasceram por causa do nível baixo do programador de hoje.
mais do mesmo. MVVC
Isso explica porque o povo prefere React Native, é uma confusão terrível esses padrões do Flutter, está cada vez mais complexo esse negócio, ao invés de facilitar criam milhares de conceitos e não se tem consenso em qual usar.
Comentário de programador fraco que só sabe JavaScript. Flutter não é melhor que React Native, é muuuito melhor. Mas se você não está disposto a aprender uma nova linguagem, fica limitado ao que sabe usar.