O Flutter vem caminhando para um nível de maturidade muito bacana com a API de Signals... Bom candidato para ser aditado como segunda opção "oficial" do flutter(além do setState).
Com certeza Rogerio, esperamos que isso pegue e como o "dono" do package é da Google, há uma via bem direta de comunicação, principalmente com a tração que o package esta tomando.
O Rodrigo Rahman fez um projeto incrível ensinando ele no Flutter Experience, descobri este gerenciador de estado através dele. Sou aluno da Academia do Flutter, e achei esse package bem legal
Muito bom! Mas francamente tenho medo dos projetos onde vou precisar dar manutenção em uns 2-3 anos. No final das contas tu tem muita liberdade de trabalhar com esse package e, via de regra é sempre a mesma história, seja com provider / changenotifier / bloc / cubit / getx🤮e por ai vai. Sem impor limites arquiteturais claros os projetos viram um bolo de regra de negócio / gestão de estado, falta de documentação / testes etc. E boa sorte p/ quem for manutenir ou arrumar a casa mais para frente. Logo, acho muito legal, bem inovador, maasss rsrs
Esse padrão é muito usado em desenvolvimento web, todos os grandes frameworks estão migrando para ele por ser simples, acho que esse vai ser o futuro, o Flutter seguir os passsos do desenvolvimento web.
Flutter é uma maldição porque tem muito package de reatividade (a galera fica na duvida em qual usa e gera até briga), porém esse parece ser promissor pois mistura varios em um só
De um Antunes para outro Antunes, parabéns pelo vídeo, sou dev fullgambiarra e tenho estudado um pouco de flutter para ver se abandono os capacitor e cordova da vida kkk
Lembra muito mesmo a idéia do VueJS que já trabalhei. Vou praticar em um dos projetos que estou desenvolvendo! Muito obrigado Professor! Vai me salvar horas rs...
Interressante demais. Se você olha a implementação que rebuilda o widget é bem legal. Acho que pode ser um boa ferramenta para otimizar o processo de atualização de widgets. Hoje se você usa outras ferramentas necessita de ter um builder por cima, nesse caso de usar o context ele ajuda você a encontrar o element e marcar que ele precisa ser rebuildado no momento que acontecer o update no signals. Gostei!
Bem isso, e bem simples de fazer. A grande questão é o core do package que é a portabilidade do Preact Signals, mas a API é bem simples mesmo. Obrigado pelo comentário @GabulDEV
@@drantunes tranquilo professor, perdi as contas de quantas vezes ja fiz isso de acabar gravando e o obs pegar o mic da webcam kkkkkk Mas deu pra entender super de boa
Sim, na verdade a ideia original é do Knockout (2010), mas ficou famoso o conceito com a implementação do Solid JS. O Vue sempre foi massa, mas a diferença do Vue de 2017 para as implementações de agora é a reatividade fine-grained (ao invés do tradicional virtual dom).
@@drantunes Sim, verdade! Acabei me confundindo com o Options API. Cheguei a usar o RFC (composables no vue 2), com algumas limitações lá em 2020 creio eu. Mas muito bom o flutter rumar para esse lado do signals, é o ideal ao meu ver mesmo. Mesmo com options e ainda mais com a reatividade (proxies) do Vue, não me fizeram nem chegar perto do React, e agora o Flutter com algo já parecido, vou ficar longe do React Native de vez kakakak
@@nero1375 Eu vou te falar (já falei abertamente aqui) - acredito. que nunca vou gostar do React. Já usei muito Vue no passado e é top até hoje. Mas hoje confesso que gosto muito da abordagem do Svelte.
@@drantunes ahahah então você me entende muito bem. Concordo, fiquei abalado em usar o Svelte, ainda mais o Sveltekit com o F7 para UI, para fazer algo mobile. Porém algo sempre me faz voltar e ver como o Flutter está (como hoje) hahahaha
Aprimorando essa pegada alá Vue, vai dar para fazer muita coisa boa sem precisar do Vue/capacitor ou perder tempo com qualquer outro state management maluco, tirando o Riverpod, que são um monte de boilerplate e confusão.
Sim, com certeza. Essa ideia está se popularizando muito muito rápido no universo JS, tanto que até o Angular correu e fez uma implementação para se reinventar. O mobile não pode ficar de fora disso.
@@drantunes sim, vou fazer alguns testes, mas acho muito verboso o uso da palavra signal, pode falar o que for, neste requisito de ser minimalista em chamadas, o getx fez bem, talvez fazer um global extension para tentar minimizar seria legal, mas é só testando mesmo 😂
Precisa pensar bem em como vai usar, mas pense que seria a mesma coisa com um monte de valuenotifier. A questão mesmo é como usar. Mais pra frente devo trazer algumas abordagens de arquitetura com os signals pra auxiliar o pessoal um pouco ;)
@@drantunes to ansioso por essas abordagens de arquitetura. Signals é muito novo e tem muito pouco conteúdo sobre. No mais valeu por falar sobre ele. Eu não conhecia.
Bem interessante esse conceito do Signals! Valeu Prof Diego pela aula! A propósito gostaria de saber sua opinião sobre o Triple, atualmente utilizo ele em meus projetos no lugar do Bloc, pois acredito que deixa mais "enxuto" a forma de se trabalhar com os states....
Muito obrigado! O Triple é interessante sim, principalmente em comunicação com APIs. Se casa bem com seu projeto vai em frente. Eu particularmente não uso, pois geralmente crio os loadings mais customizados (e.g. uma classe que possui duas variáveis de "loading" (para usar em lugares diferentes).
Se já tem um pouco da base de programação, pode ver uma playlist aqui do canal (Flutter na Prática) onde ensino a fazer um app do zero até o uso de recursos como câmera. Também tem o curso da Flutterando de 2022 gratuito no canal. E tem um do Deivid Willyan (também gratuito). Depois que fizer esses, procura ir preenchendo as lacunas do que ficou com mais dúvida.
Muito bom, so me preocupa a quantidades de effects que teremos por tela seja diretamente proporcional as propriedades que queremos fazer o watch. O codigo não tende a ficar com vários effects para cada reatividade? Eu imagino um app com telas com muitas interações e propriedades de regras negócios, isso não tende a virar um caos?
Você pode usar 1 effect para vários signals, não é 1 pra 1. Mas sim, tudo pode ficar um caos. Mesmo um ChangeNotifier que é simples, pode acabar caindo em vários builders e listeners na view :\ Mas com certeza é algo pra se pensar na hora de decidir a arquitetura.
Diego, uma pergunta simples rsss: Riverpod ou Signals + flutter_getit (ou get_it mesmo)? Sou um entusiasta de programação mas trabalho em outra área, porém tenho um projeto pessoal que pretendo finalmente tirar do papel... então minha pergunta está nesse contexto de um projeto pessoal de quem não trabalha na área e será o único responsável pelas manutenções. Agradeço sua opinião!!
Neste caso use o que for mais confortável para você... Signals tem bastante atualização, mas a API não está mudando tanto... Riverpod estou afastado há um tempo, pois estão constantemente mudando as coisas lá e não estou gostando do rumo que está tomando. get_it + signals pode ser uma boa sim, mas usa o que for melhor para você...
teu Áudio ficou ruim no momento que vc grava a tela, mas uma boa dica para quem gosta de POG. 🤣🤣🤣🤣 Mas falando serio, com padrão de projetos fica show.... At+
ValueNotifier faz somente a reatividade de um valor, digamos que "seria igual o signal". A diferença é que os signals trazem outras funções como o effect, computed, batch e outros, que auxiliam na combinação de reatividade ou a disparar ações automaticamente. A API é bem similar ao que já existe e isso é intencional, mesmo por parte das implementações em JavaScript. Mas as implementações são bem diferentes.
@@drantunes entendo fiquei curioso na parte de performance eu não sei se é, mas caso seja mais performático vale a pena o effect pra ser sincero não achei tão útil é quase um addlistener.
@@eldadario7339 Sim, acho que meu exemplo transpareceu isso. Mas dentro do effect você pode adicionar qualquer signal e o effect irá disparar para qualquer um deles. A ideia é ser uma única função ao invés de vários addListeners manuais. Mas sim, a API tende a gerar essas dúvidas (e isso é proposital). Sobre performance, ainda estão criando os benchmarks, mas no fundo no fundo, tudo será um setState no final... a grande questão de performance é na implementação para rastrear as dependências e os valores computados. Mas gostei da sua ideia: vou fazer uma implementação da mesma API só com listenables e testar a performance ;)
Sobre a questão de performance que mencionei no vídeo: a implementação do preact usa uma lista duplamente encadeada para fazer o rastreamento das dependências. Isso é uma vantagem, por exemplo, na hora de recomputar as propriedades computadas (que dependem do valor de outro signal).
@@drantunes pow bacana que legal fazer esses testes, e de verdade falar que seu conteúdo é mtt bom acompanho sempre, bem didático e com conteúdo muito bom pra se aprofundar.
Pare e pense, vc tem uma gigante de tecnologia que cria um framework para construir APPS, ok, mas, esse framework não tem um gerenciador de estado padrão, que seja 100%, daí um faz de um jeito, outro de outro, e vc tem um monte de curso ensinando Flutter cada um com um gerenciador, enfim, pensando sem emoção, isso passa confiança ?
Essa foi a escolha do time do Flutter la atrás, uma pena... Podiam ter mostrado uma forma padrão (meio que foi o BLoC, mas é tão verboso e restrito que naturalmente surgiram outras alternativas)
O Flutter vem caminhando para um nível de maturidade muito bacana com a API de Signals... Bom candidato para ser aditado como segunda opção "oficial" do flutter(além do setState).
Com certeza Rogerio, esperamos que isso pegue e como o "dono" do package é da Google, há uma via bem direta de comunicação, principalmente com a tração que o package esta tomando.
@@drantunes 🙏
Adorei essa parada, pq da pra fazer tudo bem gambiarrado igual eu gosto....
E olha que tentei não usar globais no vídeo, mas a documentação deixa isso bem explícito!
Ai falo tudo...kkkk
Isso não é uma aula, isso é uma iluminação na cabeça do dev! valeu chará!
Excelente vídeo! Esse pacote é sensacional... estou usando há um tempinho e atende muito bem as necessidades
Maneiro! É a tendência agora em 2024
O Rodrigo Rahman fez um projeto incrível ensinando ele no Flutter Experience, descobri este gerenciador de estado através dele. Sou aluno da Academia do Flutter, e achei esse package bem legal
É a tendência este ano mesmo.
Muito bom! Mas francamente tenho medo dos projetos onde vou precisar dar manutenção em uns 2-3 anos. No final das contas tu tem muita liberdade de trabalhar com esse package e, via de regra é sempre a mesma história, seja com provider / changenotifier / bloc / cubit / getx🤮e por ai vai. Sem impor limites arquiteturais claros os projetos viram um bolo de regra de negócio / gestão de estado, falta de documentação / testes etc. E boa sorte p/ quem for manutenir ou arrumar a casa mais para frente.
Logo, acho muito legal, bem inovador, maasss rsrs
Esse padrão é muito usado em desenvolvimento web, todos os grandes frameworks estão migrando para ele por ser simples, acho que esse vai ser o futuro, o Flutter seguir os passsos do desenvolvimento web.
Caraca! Sensacional, a quantidade de boilerplate que esse pacote reduz é animal!!!! Ótimo vídeo
Docuo é fo...
😂😂😂😂
Ahhh, vocês curtiram que eu sei ;)
Sensacional esse Signals. Obrigado por nos atualizar
Eu que agradeço! É uma das áreas que acho interessante e pode beneficiar o Flutter. Dependendo do Feedback de vocês trago mais materiais sobre isso.
Didática maravilhosa!! , muito bom vou dar uma lida na doc depois !!
Bons estudos! Se tiver dúvidas comenta aqui
Opa professor, vai me ajudar muito em meu aprendizado. Valeu 👍
Excelente o vídeo! Parabéns e Obrigado pelo contúdo!
Signal bem legal, gostei, parabéns professor !
Muito obrigado
Professor, tem que fazer um mini curso usando signals e routefly :D
Opa!
Flutter é uma maldição porque tem muito package de reatividade (a galera fica na duvida em qual usa e gera até briga), porém esse parece ser promissor pois mistura varios em um só
Isso mesmo! Importante é entender as vantagens, porque no fundo todos usam setState no final
Isso é um dos fatores que me deixam longe do Flutter para algo sério
@@nero1375não deveria, toda stack tem isso, desde o nativo ao web…. As empresas acabam determinando o padrão
???????@@nero1375
De um Antunes para outro Antunes, parabéns pelo vídeo, sou dev fullgambiarra e tenho estudado um pouco de flutter para ver se abandono os capacitor e cordova da vida kkk
Lembra muito mesmo a idéia do VueJS que já trabalhei. Vou praticar em um dos projetos que estou desenvolvendo! Muito obrigado Professor! Vai me salvar horas rs...
Com certeza! A implementação do Vue é um pouco diferente, mas a ideia dos Refs é praticamente a mesma.
Interressante demais. Se você olha a implementação que rebuilda o widget é bem legal. Acho que pode ser um boa ferramenta para otimizar o processo de atualização de widgets. Hoje se você usa outras ferramentas necessita de ter um builder por cima, nesse caso de usar o context ele ajuda você a encontrar o element e marcar que ele precisa ser rebuildado no momento que acontecer o update no signals. Gostei!
Bem isso, e bem simples de fazer. A grande questão é o core do package que é a portabilidade do Preact Signals, mas a API é bem simples mesmo. Obrigado pelo comentário @GabulDEV
Prevejo o Signals hell..... Cuidado, siga a luz do bloc boilerplate. rs ... Ótimo vídeo!
muito obrigado por divulgar essa lib, vai ser muito util pra mim, vlw mano
Top de mais, vou estudar por aqui para implantar nos projetos. ❤😊
Achei muito interessante! A implantação é bem simples.
Também gostei! Vou preparar um exemplo mais real pra fazer um aulão ;)
Professor, _seu menino_, que informações interessantes... obrigado por estas matérias interessantes... 👏
Obrigado Alex! Grande abraço
Gostei d+ do signals, uso riverpod em um app e em algumas partes o setState, estou substituindo a parte do setState pelo signals.
É bom sempre explorar as novas tecnologias para entender os potenciais delas. Com certeza irei explorar mais por aqui.
vish gravou com o audio da webcam? quem nunca kkkk
Topzera
calma nutellinha ;p
Ueh
Deu pau no microfone e pegou o microfone do computador de longe :/
Nó próximo ja tento corrigir
@@drantunes tranquilo professor, perdi as contas de quantas vezes ja fiz isso de acabar gravando e o obs pegar o mic da webcam kkkkkk
Mas deu pra entender super de boa
Achei muito interessante o Signals. Obrigado por compartilhar Prof.
Obrigado Renato!
Muito interessante! Ótimo conteúdo Diego haha!
Muito obrigado pelo conteúdo, estava nesse exato momento procurando mais conteúdo sobre o pacote quando recebi a notificação do vídeo
Sucesso!!! Minha bola de cristal avisou! Se ficar com duvida comenta aqui
Muito bom o vídeo. Parabéns. Vou fazer uns testes nos meus projetos
Lembrou bastante a ideia do Vue
Exato, VueJS a frente de seu tempo desde 2020
Sim, na verdade a ideia original é do Knockout (2010), mas ficou famoso o conceito com a implementação do Solid JS. O Vue sempre foi massa, mas a diferença do Vue de 2017 para as implementações de agora é a reatividade fine-grained (ao invés do tradicional virtual dom).
@@drantunes Sim, verdade! Acabei me confundindo com o Options API. Cheguei a usar o RFC (composables no vue 2), com algumas limitações lá em 2020 creio eu. Mas muito bom o flutter rumar para esse lado do signals, é o ideal ao meu ver mesmo.
Mesmo com options e ainda mais com a reatividade (proxies) do Vue, não me fizeram nem chegar perto do React, e agora o Flutter com algo já parecido, vou ficar longe do React Native de vez kakakak
@@nero1375 Eu vou te falar (já falei abertamente aqui) - acredito. que nunca vou gostar do React. Já usei muito Vue no passado e é top até hoje. Mas hoje confesso que gosto muito da abordagem do Svelte.
@@drantunes ahahah então você me entende muito bem. Concordo, fiquei abalado em usar o Svelte, ainda mais o Sveltekit com o F7 para UI, para fazer algo mobile. Porém algo sempre me faz voltar e ver como o Flutter está (como hoje) hahahaha
DOCUO 😂😂😂😂 MANO..., importante é o patrocínio dane-se o nome kkkk.. parabéns pelas infos ❤
Obrigado 🙏 estamos precisando para manter o canal
@@drantunes sempre acompanho, sua didática é muito boa, quero ajudar de alguma forma você manter o canal ativo. 👍
Stacked melhor state managment
Gostei muito! Irei usar nos meus novos projetos
Ducuo é foda
sim KKKKK morri de rir disso
🎉🎉🎉
gostei, uma pergunta saberia informar, se Signals é mais leve do o Getx, na coplilação?
Não entendo bem o que quer dizer com pesado ou leve, mas signals só faz a reatividade e nada mais.
Aprimorando essa pegada alá Vue, vai dar para fazer muita coisa boa sem precisar do Vue/capacitor ou perder tempo com qualquer outro state management maluco, tirando o Riverpod, que são um monte de boilerplate e confusão.
Sim, com certeza. Essa ideia está se popularizando muito muito rápido no universo JS, tanto que até o Angular correu e fez uma implementação para se reinventar. O mobile não pode ficar de fora disso.
@@drantunes parece-me que o Composable do Android está com uma pegada parecida(não tanto que nem o solid, neste caso)
@@nero1375 É uma tendência, assim com o foi com UI Declarativa. Vejo todo mundo migrando pra isso "para não ficar pra trás"
@@drantunes ao menos, nesse caso é uma coisa ótima. Concorrência sempre é bom ahahaha
@@nero1375 de fato
Incrível como sempre
Obrigado meu amigo!!
Me lembrou bastante o Getx
É um bom replacement, basta fazer os wrappers e booomm ;)
@@drantunes sim, vou fazer alguns testes, mas acho muito verboso o uso da palavra signal, pode falar o que for, neste requisito de ser minimalista em chamadas, o getx fez bem, talvez fazer um global extension para tentar minimizar seria legal, mas é só testando mesmo 😂
@@gelsoncarlos2955 sim, 4 linhas de código resolve isso
Excelente vídeo professor! Vamos ver se o Signals vai pegar
Obrigado Debora! Assim esperamos e sempre pensando em tornar o Flutter melhor e mais simples.
manda muito! valeu pelo conteúdo
Eu que agradeço
Inicialmente parece bem mais simples que os outros gerenciadores, mas será que logo não fica muito caótico a quantidade de signals?
Precisa pensar bem em como vai usar, mas pense que seria a mesma coisa com um monte de valuenotifier. A questão mesmo é como usar. Mais pra frente devo trazer algumas abordagens de arquitetura com os signals pra auxiliar o pessoal um pouco ;)
@@drantunes Essa ideia de trazer um video de arquitetura com signal é genial!
@@drantunes to ansioso por essas abordagens de arquitetura. Signals é muito novo e tem muito pouco conteúdo sobre. No mais valeu por falar sobre ele. Eu não conhecia.
Bem interessante esse conceito do Signals! Valeu Prof Diego pela aula! A propósito gostaria de saber sua opinião sobre o Triple, atualmente utilizo ele em meus projetos no lugar do Bloc, pois acredito que deixa mais "enxuto" a forma de se trabalhar com os states....
Muito obrigado! O Triple é interessante sim, principalmente em comunicação com APIs. Se casa bem com seu projeto vai em frente. Eu particularmente não uso, pois geralmente crio os loadings mais customizados (e.g. uma classe que possui duas variáveis de "loading" (para usar em lugares diferentes).
Me indique um curso bom para iniciantes em Dart e Flutter !!!
Se já tem um pouco da base de programação, pode ver uma playlist aqui do canal (Flutter na Prática) onde ensino a fazer um app do zero até o uso de recursos como câmera. Também tem o curso da Flutterando de 2022 gratuito no canal. E tem um do Deivid Willyan (também gratuito). Depois que fizer esses, procura ir preenchendo as lacunas do que ficou com mais dúvida.
Perfeito 🎉
Obrigado João!!
Muito bom , valeu !!
Eu que agradeço!!!
Muito bom, so me preocupa a quantidades de effects que teremos por tela seja diretamente proporcional as propriedades que queremos fazer o watch. O codigo não tende a ficar com vários effects para cada reatividade? Eu imagino um app com telas com muitas interações e propriedades de regras negócios, isso não tende a virar um caos?
Você pode usar 1 effect para vários signals, não é 1 pra 1. Mas sim, tudo pode ficar um caos. Mesmo um ChangeNotifier que é simples, pode acabar caindo em vários builders e listeners na view :\
Mas com certeza é algo pra se pensar na hora de decidir a arquitetura.
Muito legal 🎉
Obrigado Ewerton!
Diego, uma pergunta simples rsss: Riverpod ou Signals + flutter_getit (ou get_it mesmo)? Sou um entusiasta de programação mas trabalho em outra área, porém tenho um projeto pessoal que pretendo finalmente tirar do papel... então minha pergunta está nesse contexto de um projeto pessoal de quem não trabalha na área e será o único responsável pelas manutenções. Agradeço sua opinião!!
Neste caso use o que for mais confortável para você... Signals tem bastante atualização, mas a API não está mudando tanto... Riverpod estou afastado há um tempo, pois estão constantemente mudando as coisas lá e não estou gostando do rumo que está tomando. get_it + signals pode ser uma boa sim, mas usa o que for melhor para você...
Diego uma duvida eu vi um exemplo de projeto no github que estava usando signals e build runner em algum momento o signals precisa de build runner ??
Não precisa, pode ser alguma outra funcionalidade do o projeto estava usando...
docuo nao vai pegar bem aqui no brasil kkk
cara quando ele falou o nome da plataforma eu rachei de rir
KKKKKKKKKK eu rachei tambem, 'conheça agora o docu' KKKKKKKKKKKKK a 5 serie nao sai da gente@@Gabonidaz
Ou vai bem por isso 💙
teu Áudio ficou ruim no momento que vc grava a tela, mas uma boa dica para quem gosta de POG. 🤣🤣🤣🤣
Mas falando serio, com padrão de projetos fica show....
At+
React 🤝 Flutter
legal mas pq isso ao inves do valuenotifier?
ValueNotifier faz somente a reatividade de um valor, digamos que "seria igual o signal". A diferença é que os signals trazem outras funções como o effect, computed, batch e outros, que auxiliam na combinação de reatividade ou a disparar ações automaticamente. A API é bem similar ao que já existe e isso é intencional, mesmo por parte das implementações em JavaScript. Mas as implementações são bem diferentes.
@@drantunes entendo fiquei curioso na parte de performance eu não sei se é, mas caso seja mais performático vale a pena o effect pra ser sincero não achei tão útil é quase um addlistener.
@@eldadario7339 Sim, acho que meu exemplo transpareceu isso. Mas dentro do effect você pode adicionar qualquer signal e o effect irá disparar para qualquer um deles. A ideia é ser uma única função ao invés de vários addListeners manuais. Mas sim, a API tende a gerar essas dúvidas (e isso é proposital).
Sobre performance, ainda estão criando os benchmarks, mas no fundo no fundo, tudo será um setState no final... a grande questão de performance é na implementação para rastrear as dependências e os valores computados.
Mas gostei da sua ideia: vou fazer uma implementação da mesma API só com listenables e testar a performance ;)
Sobre a questão de performance que mencionei no vídeo: a implementação do preact usa uma lista duplamente encadeada para fazer o rastreamento das dependências. Isso é uma vantagem, por exemplo, na hora de recomputar as propriedades computadas (que dependem do valor de outro signal).
@@drantunes pow bacana que legal fazer esses testes, e de verdade falar que seu conteúdo é mtt bom acompanho sempre, bem didático e com conteúdo muito bom pra se aprofundar.
Pare e pense, vc tem uma gigante de tecnologia que cria um framework para construir APPS, ok, mas, esse framework não tem um gerenciador de estado padrão, que seja 100%, daí um faz de um jeito, outro de outro, e vc tem um monte de curso ensinando Flutter cada um com um gerenciador, enfim, pensando sem emoção, isso passa confiança ?
Essa foi a escolha do time do Flutter la atrás, uma pena... Podiam ter mostrado uma forma padrão (meio que foi o BLoC, mas é tão verboso e restrito que naturalmente surgiram outras alternativas)
Minha quinta série não aguenta com esse patrocinio kkkkkkkkkkkkkkkkkkkkk pqp kkkk
Com certeza, mas faz parte… canal está precisando!
Só tenho uma coisa a dizer: adeus mobx e bloc lixo.
Lá ele, gostei dessa plataformar não, tô fora kkkkk
Não criemos pânico 💙
context to fora kkk
Speak English