Atualização de estado de uma tela de listagem com bloc_libary

[gabriellopesjds]

Cenário: Dado que tenho uma tela de listagem ( ListView ), onde a lista que apresenta os dados estão sendo gerenciado através do BLOC, quando o usuário clicar em um FloatingActionButton para cadastrar / editar um novo elemento, então ele vai ser redirecionado para uma nova tela que ao salvar, deve ser redirecionado para tela de listagem com os dados já atualizados.

Estou utilizando Provider para injeção de dependências e bloc_libary para gerenciamento de estados.

Hoje estou fazendo assim, quando o usuário salva, chamo meu service > bussiness > repository, que salva o objeto no meu DB ( SQLite ), na sequencia faço um findAll no meu repository e atualizo o BLOC que gerencia minha ListView.

Queria saber qual é a melhor prática para realizar esse processo, podem me ajudar ?

[jacobaraujo7]

Olá.
Acredito que essa não é uma dúvida sobre um problema específico. Então estou movendo para "Discursões gerais".

[eduardoflorence]

@gabriellopesjds, segundo a documentação oficial do Bloc, uma abordagem "aconselhável" é transformar o retorno do seu findAll num Stream para que sua lista responda automaticamente às alterações. Você pode ver o exemplo nesta parte da documentação:
https://bloclibrary.dev/#/fluttertodostutorial

Uma outra solução que já usei em alguns projetos de menor complexidade é ter um único Bloc para atender a página de lista e a página de edição de um objeto da lista, ou seja, seu estado teria uma propriedade com a lista e uma outra propriedade com o objeto da lista que está sendo alterado/incluído no momento, sendo que este estaria nulo/vazio quando a página de lista estiver ativa. O grande objetivo era não ter que fazer uma busca de toda a lista a cada operação de CRUD, bastando emitir um novo estado com a lista inicial e sua alteração/inclusão. Obs.: Ao alterar uma propriedade do tipo Lista em um estado, utilize List.from

[gabriellopesjds]

hmmm, vou avaliar as possibilidades @eduardoflorence , obrigado por compartilhar !

[cbalmeida]

Gabriel, na minha opinião a melhor forma é: "depende"!

Existem várias formas de implementar isso e a "melhor" delas vai depender de vários fatores, mas o principal é o volume de dados que voce vai trafegar ao fazer o seu "refresh".

Vamos supor que voce esteja trazendo algumas centenas ou mesmo alguns milhares de registros, ou seja, que esteja consumindo uma api muito mal implementada e sem nenhum recurso de paginação. Neste caso eu realmente NÃO aconselho a fazer um "refresh" de tudo so para trazer 1 registro a mais! É preciso considerar a carga sobre o servidor, o volume de bytes trafegados, etc, etc, etc, que representam custos para ambos os lados.

Neste cenário apocalíptico, eu simplesmente iria adicionar o registo à lista ja existente (que ja está na memoria) logo depois que a api confirmasse que o registro foi devidamente gravado. Porém o "caveat" desta abordagem é que o registro pode sofrer alguma alteracao no backend durante o processo de gravacao (algum trigger que altera algum valor de coluna, etc), e o fato de voce inserir manualmente na lista pode mascarar algum valor que foi alterado no backend e que voce não tem por nao ter feito o refresh. A vantagem é economizar (e muito) no trafego de dados e na carga do servidor, e consequentemente, salvar dinheiro.

Já num cenário com muito menos registros (algumas unidades até poucas dezenas), eu costumo fazer o "refresh" da lista toda a partir do servidor, pois neste caso a gente garante estar mostrando para o usuário exatamente aquilo que está persistido no backend.

Mas mesmo que o servidor tenha paginação, é preciso ter cuidado ao dar o refresh "parcial", pois pode ocorrer do registro inserido não estar visivel na "pagina" que está sendo visualizada, e com isto o usuario terá a impressão que o registro não foi "gravado" e pode acabar inserindo novamente e causar mais transtornos.

Como ja dito pelo @eduardoflorence, o ideal é que a sua api implementasse "stream" de dados (a exemplo do firebase), onde voce recebe de "volta" somente aquilo que foi "inserido/alterado/excluido". Esta sim é a solucao ideal que atende todos os casos de forma eficiente e sem transtornos.