Espero que em algum momento consigamos superar esse tópico de "State management" , acredito que desde da chegada do BloC (Até antes disso) passou a ter muita confusão e discussão em relação a qual o melhor, sendo que não existe "O Mellhor gerenciador" o peso todo disso tá no Desenvolvedor e é uma pena que muitas pessoas não vejam dessa forma e achem que a biblioteca vai suprir isso completamente, temos de amadurecer quanto a isso.
Então resumindo, um gerenciador de estado precisa de funções para manejar o estado de entrada e saida, enquanto o provider/context precisa estar na arvore de composição do projeto, em um nivel superior, pra poder distribuir os dados?!
Sim, mas pode ficar mais simples. Gerenciar o estado é literalmente saber onde guardar e modificar o objeto de estado, enquanto o provider apenas distribui esse objeto pela arvore
Bah, saquei a diferença. Uma pergunta: se eu salvar o dado em SharedPreference, esse salvamento cabe dentro de um bloc? Seria prudente eu abstrair esse salvamento em um serviço antes sequer de expor ele no bloc?
Então, sobre o contexto api ele em si não é um gerenciador de estados . Mas, vc consegue fazer com que ele desempenhe tal papel e isso não é gambiarra. O próprio redux no react utiliza ele pra fazer a gerencia
Não confunda as coisas, vou dar um exemplo similar no Flutter: o bloc_flutter é gerenciador de estados e Provider pode ser usado como injeção de dependencias, e o BloC usa Provider como dependencia, e não é porque ele usa internamente que consigo fazer o mesmo que o BloC com o provider! A menos que eu faça toda estrutura similiar ao próprio BloC, o que é pouco inteligente.
@@rdrgbaioco mano, ninguém confundiu nada. Eu falei do react e não do bloc. E sim, vc consegue fazer gerenciamento de estado com contexto api, se no providers não dá ou é difícil, pouco inteligente, aí é outra história e é vc quem está falando. O ponto é, gerenciamento de estado, se vc consegue fazer isso do zero, blz. Mas vc tem que ter a consciência disso.
@@flawtista Aqui esta tratando de Flutter (a exemplo, o título) e de pacotes, do zero tudo é possível de acordo com a capacidade da pessoa. Já os pacotes cada um tem seu objetivo, se puro (sem gambiarras) ele não faz algo, ele não é esse algo e ponto. Se pra você serviu, é porque com toda certeza você colocou outros códigos para suprir o que ele não faz, e a partir disso tu sabe que ele não é o que diz.
@@rdrgbaioco sim eu sei disso. Eu apenas reforcei o ponto que, vc tem que saber o que está fazendo. Um ponto que foi falado pelo Jacob no vídeo. Como ele falou de react, falei que ser e fazer são verbos diferentes. Portanto, não entendi quando vc falou q eu confundi as coisas. Tudo dá pra ser feito, a diferença é que vc tem que saber o que está fazendo, e então vc precisa saber os conceitos e pra que serve as ferramentas. E como contexto api é um recurso de compartilhamento de dados, e pela forma que o react é construído, vc consegue fazer uma gerenciamento de estado, mas vc tem que saber como vc vai se utilizar desse arcabouço pra atender tal finalidade. Isso não implica que o context api é uma gerenciador de estado, mas eu por conhecer os conceitos e saber exatamente o que eu quero, eu vou implementar uma gerenciador de estado. Esses foi o meu ponto. Se com o providers é inviável fazer isso, blz. Mas não foi isso que eu falei. Sacou?
O que supre a sua necessidade, você pode gerenciar com setState e tá tudo bem! Agora temos diversas bibliotecas que nos ajudam trazendo padrões para facilitar na hora de desenvolvermos, além de claro evitarem que reinventemos a roda toda hora ou façamos uma gerência própria sem padrão algum.
O vídeo citado
ua-cam.com/video/KRQmSw5wN0s/v-deo.html
Muito obrigado por esse vídeo 🙏🏻 me ajudou demais, ótimo conteúdo!!!
Top demais... Jacob muito obrigado 🙏!
Fantástico! Também disponibilizamos em nosso canal uma playlist em andamento sobre como desenvolver um CRUD completo de usuário em Flutter!
Ótima explicação sobre gerência de estado.
Obrigado por tudo que você fez de contribuições para a comunidade brasileira de flutter maninho! Tamo junto.
se o flutter mostra-se só maneiras nativas de lidar com o estado já tava perfeito
Espero que em algum momento consigamos superar esse tópico de "State management" , acredito que desde da chegada do BloC (Até antes disso) passou a ter muita confusão e discussão em relação a qual o melhor, sendo que não existe "O Mellhor gerenciador" o peso todo disso tá no Desenvolvedor e é uma pena que muitas pessoas não vejam dessa forma e achem que a biblioteca vai suprir isso completamente, temos de amadurecer quanto a isso.
Definitivamente necessário esse vídeo.
Então resumindo, um gerenciador de estado precisa de funções para manejar o estado de entrada e saida, enquanto o provider/context precisa estar na arvore de composição do projeto, em um nivel superior, pra poder distribuir os dados?!
Sim, mas pode ficar mais simples.
Gerenciar o estado é literalmente saber onde guardar e modificar o objeto de estado, enquanto o provider apenas distribui esse objeto pela arvore
@@FlutterandoTV Informação extremamente importante, porque lendo a doc realmente não é informado a diferença. Vlw pelo conteúdo!!!
Bah, saquei a diferença.
Uma pergunta: se eu salvar o dado em SharedPreference, esse salvamento cabe dentro de um bloc? Seria prudente eu abstrair esse salvamento em um serviço antes sequer de expor ele no bloc?
Então, sobre o contexto api ele em si não é um gerenciador de estados . Mas, vc consegue fazer com que ele desempenhe tal papel e isso não é gambiarra. O próprio redux no react utiliza ele pra fazer a gerencia
Não confunda as coisas, vou dar um exemplo similar no Flutter: o bloc_flutter é gerenciador de estados e Provider pode ser usado como injeção de dependencias, e o BloC usa Provider como dependencia, e não é porque ele usa internamente que consigo fazer o mesmo que o BloC com o provider! A menos que eu faça toda estrutura similiar ao próprio BloC, o que é pouco inteligente.
@Ariel Sardinha sim não é o intuito do vídeo. Apenas reforcei um ponto que ele mesmo comentou, de vc utilizar de recursos pra gerenciar seus estados.
@@rdrgbaioco mano, ninguém confundiu nada. Eu falei do react e não do bloc. E sim, vc consegue fazer gerenciamento de estado com contexto api, se no providers não dá ou é difícil, pouco inteligente, aí é outra história e é vc quem está falando. O ponto é, gerenciamento de estado, se vc consegue fazer isso do zero, blz. Mas vc tem que ter a consciência disso.
@@flawtista Aqui esta tratando de Flutter (a exemplo, o título) e de pacotes, do zero tudo é possível de acordo com a capacidade da pessoa.
Já os pacotes cada um tem seu objetivo, se puro (sem gambiarras) ele não faz algo, ele não é esse algo e ponto.
Se pra você serviu, é porque com toda certeza você colocou outros códigos para suprir o que ele não faz, e a partir disso tu sabe que ele não é o que diz.
@@rdrgbaioco sim eu sei disso. Eu apenas reforcei o ponto que, vc tem que saber o que está fazendo. Um ponto que foi falado pelo Jacob no vídeo. Como ele falou de react, falei que ser e fazer são verbos diferentes. Portanto, não entendi quando vc falou q eu confundi as coisas. Tudo dá pra ser feito, a diferença é que vc tem que saber o que está fazendo, e então vc precisa saber os conceitos e pra que serve as ferramentas. E como contexto api é um recurso de compartilhamento de dados, e pela forma que o react é construído, vc consegue fazer uma gerenciamento de estado, mas vc tem que saber como vc vai se utilizar desse arcabouço pra atender tal finalidade. Isso não implica que o context api é uma gerenciador de estado, mas eu por conhecer os conceitos e saber exatamente o que eu quero, eu vou implementar uma gerenciador de estado. Esses foi o meu ponto. Se com o providers é inviável fazer isso, blz. Mas não foi isso que eu falei. Sacou?
Já que o Provider não é um gerenciador de estado, hoje qual é o melhor cara para gerenciar estado no Flutter?
Nao tem melhor
O que supre a sua necessidade, você pode gerenciar com setState e tá tudo bem! Agora temos diversas bibliotecas que nos ajudam trazendo padrões para facilitar na hora de desenvolvermos, além de claro evitarem que reinventemos a roda toda hora ou façamos uma gerência própria sem padrão algum.
Esse mesmo erro ocorre com o riverpod 😅
Sim kkkkk