Gerenciamento de estado — Provider

Ora, já deu para perceber o que é o gerenciamento de estado e como aplicar em uma aplicação de pequeno porte e sem necessidade de carregar dados pela aplicação, mas e se a aplicação crescer e ser necessário gerir os dados em vários pontos da aplicação? Aí surgem as outras abordagens de gerenciamento, que são algumas bibliotecas preparadas para tal, como é o caso do Provider que será debruçado ao longo deste artigo.

Este artigo faz parte de uma série de 5 artigos que vão abordar vários padrões de gerenciamento de estado.

1. State Management — Introdução
2. State Management — Provider (este artigo)
3. State Management — Bloc
4. State Management — Redux
5. State Management — Mobx

Provider

Provider em flutter é basicamente um recurso que permite monitorar, receber, notificar e permitir consumo de mudanças em uma aplicação a partir de seus auxiliares Notifier, Provider e Consumer, que será abordado mas adiante.
Para perceber melhor sobre os providers tomemos como exemplo uma empresa qualquer (organizada nem rsrsrsr) onde temos lá os seguranças/guardas, recepcionistas e os executivos (e outros) que recebem o visitante que será o nosso objecto para este exemplo. Temos a recepcionista preparada para receber e encaminhar o hóspede, por sua vez o guarda monitora os movimentos e se calhar informar de algum movimento fora do comum ou seguindo protocolos caso haja necessidade. Então no final das contas temos o guarda que serve como notifiers, o recepcionista que é um provider e os executivos que são os consumers.

Notifiers

Como já foi explicado, os notifiers são uma espécie de guardas prontos a agir caso haja alguma mudança nas predefinições do estado do elemento a que está vinculado. Para gerir essas mudanças podem ser usadas duas classes maioritariamente de entre as várias que se podem encontrar na documentação do provider para múltiplos fins, que são o ChangeNotifier e o ValueNotifier (verifique no link da documentação ValueListnableProvider ou vá directo a foundation>ValueNotifier). O ChangeNotifier é o 101 dos Notifiers que avisa quando acontece qualquer mudança e o ValueNotifier leva um valor inicial e avisa quando este elemento tem seu valor alterado.

Providers

Agora, imaginemos que temos alguém a vigiar mas a informação nunca chega a quem é de direito? Para contornar este problema colocamos os recepcionistas de modo a facilitar a comunicação e permitir que a informação chegue, analogamente, os providers passam a informação referente à mudança e apresentam ao elemento vinculado a esta mudança. De entre os vários Providers que temos disponíveis acho importante falar de quatro deles que são o ChangeNotifierProvider, StreamProvider, FutureProvider e o MultiProvider.

• MultiProvider — para falar do MultiProvider como classe e recurso para lidar com informação usando providers é importante conhecer o Provider de forma isolada (sem os notifiers e consumers). O provider é uma classe que providencia informação à nossa widget tree quando esta é construída. Apenas isso! Agora que sabemos o que faz o Provider, imagina que nós precisamos reutilizar o Provider (dica: isso é impossível). Então será que apenas temos direito a uma única utilização em nossa aplicação? Não! O MultiProvider permite passar para a nossa widget tree n informações vindo de modelos diferentes. Mas o que são modelos? Modelos são classes onde definimos os valores passados ao provider e as acções que os mesmos efectuam quando chamados.
• ChangeNotifierProvider — como foi explicado, o Provider em si apenas passa valor(es) [caso seja um MultiProvider], mas e se nós pretendemos realmente gerenciar estados e permitir alterações por meio de um botão por exemplo para adicionar ou remover itens do carrinho, ou voltando ao exemplo acima, imagina que a mudança chegue e o segurança não vê, considera-se uma violação e em alguns casos se quer lhe permitem chegar ao executivo porque não possui algum tipo de aceitação ou guia. Portanto, o ChangeNotifierProvider é associado à classe modelo de modo permitir que sempre que este sofrer alguma alteração por meio de alguma acção este lance uma “notificação” ao provider de modo a lançá-la para o elemento vinculado.
• FutureProvider — O FutureProvider comporta-se como um Provider básico, a única diferença é que é usado com dados futures (pode ver os artigos que falam de futures), ou seja, para permitir mudanças usa-se o ChangeNotifierProvider.
• StreamProvider — permite providenciar dados stream e herdam o comportamento dos mesmos. Mais sobre Streams aqui.

NOTA: O FutureProvider e o StreamProvider não respondem a mudanças do future e streams, respectivamente. Para que isso seja alcançado é necessário usar o ChangeNotifierProvider.

Consumers

Como já foi explicado este é quem recebe as informações relativas a mudanças, só há que esclarecer que o mesmo não precisa ser exactamente o elemento a aparecer com o dado na tela, isto é, ele recebe outros widgets que irão usar na prática os dados. Os consumers podem ser o Provider.of, Consumer e Selector. O Provider.of pega o Provider mais próximo e pode ser associado a um tipo; o Consumer busca o Provider.of e constrói um novo widget e o; Selector é um consumer “inteligente” que escuta se realmente há mudanças e só assim reconstrói o widget.

Como implementar o Provider

provider: ^4.1.2

Na Prática

Neste exemplo usamos o demo oferecido pela equipe do Flutter e modificamos para reduzir e aumentar (o tempo do covid rsrsrsr), e apresentar noutra tela. Toda alteração é controlada por um provider, assim como a entrega do valor na UI.

Nota: Pode contribuir o projecto completo no meu repositório do github.

Espero que tenha aprendido com este artigo e que se tenha divertido enquanto lia.

Obrigado por acompanhar até ao fim e espero por você nos próximos artigos.

Para questões e sugestões esteja a vontade para tal nos comentários, email igorlsambo1999@gmail.com ou twitter @lsambo02.

Obrigado e até ao próximo artigo!!!