Gerência de Estados no Flutter

Neste post vamos introduzir o básico sobre Gerência de Estados no Flutter, além de descobrir o que é, porquê e como funciona. Não iremos nos aprofundar sobre o Widget ou afins da linguagem, talvez em uma próxima e se você tiver interesse pode deixar nos comentários ao final deste post. 😜

O que são “Estados”

Primeiro, o que é “Estado” afinal? Bom, tratando-se da palavra temos vários significados. O Brasil é composto por 26 estados, por exemplo, mas, no contexto de software o “Estado” é uma combinação do valor original mais as modificações ao longo do tempo, ou seja, “Estado” é uma informação em um determinado ponto do tempo, e essa informação pode ser um status, uma condição, transação, etc.

No nosso dia a dia podemos ver vários exemplos, como as luzes semáforo, falo sobre as luzes porque você pode ser chato e falar que o semáforo, na verdade, é uma máquina de estados finita, mas isso é assunto para outra hora. hehe 🙂

As luzes do semáforo tem dois estados, ligado e desligado, em conjunto elas formam o semáforo, que tem 3 estados sinalizados por cores, sendo: verde (sinaliza para os motoristas que o caminho está livre para ser seguido), amarelo (sinaliza que o sinal está prestes a fechar) e vermelho (sinaliza que a passagem está bloqueada), isso no ponto de vista do motorista, pois, os pedestres interpretam de outra maneira.

 

No Contexto de Software

Se você é do clube do JavaScript então você está acostumado com estados, seja mudando um valor na UI (User Interface) com a API nativa ou com o poder do ReactJS. No Flutter é bem parecido, vamos à algo mais visual, como, por exemplo, uma aplicação que gera um número aleatório de 1 até 1000:

Usando a API do ReactJS, você nota que usamos o hook useState e dele fazemos uma atribuição via desestruturação sendo uma variável (é um estado), number e uma função que chamamos de setNumber (define o “valor” do estado).

A lógica não importa tanto, preste atenção à variável number que é usada dentro da tag p no HTML, de acordo com o click, nós vamos mudando o valor dela mas também usamos ela para exibir, ou não, o número randômico, isso porque inicialmente ela é undefined, este é o estado inicial dela!

A ideia é fazer o usuário clicar no botão para obter um novo número, e este é o resultado:

Vamos dar uma olhada em como fazemos isso no Flutter! Vou considerar que você já sabe o básico de Dart e o básico sobre Widgets.

class _MyHomePageState extends State<MyHomePage> {
 int? number;
 int generateRandomNumber() {
   return (new Random()).nextInt(1000) + 1;
 }
 void handleClickEvent() {
   setState(() => {number = generateRandomNumber()});
 }
 @override
 Widget build(BuildContext context) {
   return Scaffold(
     appBar: AppBar(
       title: Text(widget.title),
     ),
     body: Container(
       child: Center(
         child: Column(
           mainAxisAlignment: MainAxisAlignment.center,
           children: [
             SizedBox(
               height: 40.0,
               child: Text(
                 number == null
                     ? 'Click in the button bellow to generate random number'
                     : "Random number: $number",
               ),
             ),
             ElevatedButton(
               onPressed: handleClickEvent,
               child: Text('Generate a number!'),
             ),
           ],
         ),
       ),
     ),
   );
 }
}

Hehe, mudamos para o Dart então as coisas são um pouco diferentes, mas parecidas, fizemos a mesma coisa e olha, temos um setState (setNumber) também!
Temos praticamente o mesmo resultado visualmente:
Depois do click:

Mas, pô, praticamente? Sim! Diferente do React, o setState ou setNumber, redesenha toda a UI (para ser mais justo, o método build é executado novamente)! Se você olhar o código fonte para ver como o setState funciona, verá que ele marca como “needsBuild” um dos 60 frames e assim o framework sabe que é necessário um rebuild.

Você consegue usar o setState para construir uma aplicação inteira, com um certo nível de acoplamento você pode nem precisar usar!

Porém, a coisa vai ficar complicada dependendo do peso da sua aplicação, das telas, e dos contextos que precisarão de uma informação que está em outra seção, dos componentes e até do backend…

Vamos ver na pŕatica o setState redesenhando a UI. A única coisa que eu vou mudar no código é o título da appBar e por enquanto, vou tirar o setState de cena:

Estamos concatenando o título + o resultado da função, e mesmo clicando no botão, nada acontecerá!

Esse comportamento faz sentido visto que a tela já foi desenhada, e aquele número vai ficar estático até que algo redesenhe a tela de novo! Então, colocando o setState de volta, perceberemos que o valor não é mais estático, ele muda a cada click! Mesmo que eu não esteja usando o number (estado) lá!

Isso acontece, pois, mesmo usando um widget stateless, um widget que não precisamos manter o estado dele, o mesmo é re-renderizado, pois, o build acontece novamente!

Então como podemos fazer para que o comportamento seja o mesmo comportamento do React?

Para atualizar apenas o local em que usamos o estado (listeners), precisamos de um Gerenciador de Estado, temos vários e você certamente encontrará suporte da comunidade em qualquer um deles: GetX, BloC, MobX entre outros…

Há uma grande briga na comunidade sobre qual é melhor ou coisas do tipo, cada um tem suas nuances e para os próximos exemplos irei usar o GetX.

Existem algumas formas de fazer esse app genérico de gerar números aleatórios, vamos usar um controller no exemplo para separar a view da lógica. Você pode conferir a sintaxe e como usar o Get na documentação do componente [https://pub.dev/documentation/get/latest/]. Nossa lógica no Get ficará assim:

class ControllerExample extends GetxController {
 var number = 0.obs;
 int generateRandomNumber() {
   return (new Random()).nextInt(1000) + 1;
 }
 void handleClickEvent() {
   number.value = this.generateRandomNumber();
 }
}

Não seria tão diferente usando o ChangeNotifier ou outros packages. No caso do Get, para indicarmos que uma variável é um estado, colocamos a notação .obs, de observable, no valor inicial da variável. Por quê?
Nesse exemplo estamos usando um dos tipos de gerenciamento de estados do Get, o Gerenciamento Reativo! O Get nos provê dois tipos: o Gerenciamento de Estados Simples e o Gerenciamento Reativo.

Simples x Reativo

Explicando brevemente a diferença entre os dois, quando não precisamos passar o estado adiante (para outras telas) usamos o Gerenciamento Simples, o nosso código ficaria assim:

class Example extends StatelessWidget {
 var number = 0.obs;
 int generateRandomNumber() {
   return (new Random()).nextInt(1000) + 1;
 }
 void handleClickEvent() {
   number.value = generateRandomNumber();
 }
 @override
 Widget build(BuildContext context) {
   return Column(
     mainAxisAlignment: MainAxisAlignment.center,
     children: [
       SizedBox(
         height: 40.0,
         child: Obx(
           () => Text(
             number.value == 0
                 ? 'Click in the button bellow to generate random number'
                 : "Random number: ${number}",
           ),
         ),
       ),
       ElevatedButton(
         onPressed: handleClickEvent,
         child: Text('Generate a number!'),
       ),
     ],
   );
 }
}

Note que nesse exemplo nós envolvemos o widget Text dentro de outro, o Obx, um widget do GetX para que possamos ouvir os observables.

Já, se queremos separar a lógica da view, ou se queremos passar uma informação adiante, o ideal é usar o Gerenciamento Reativo, isso porque o Get usa esse paradigma (programação reativa) em sua composição, e utiliza de streams para controlar os estados de maneira assíncrona.

É assim que ele sabe se um estado mudou ou não, e daí decide se deve ou não atualizar a UI, trazendo performance e certeza de que o estado realmente mudou.

Gerenciamento Reativo em prática

Como eu ia dizendo, vamos usar a maneira Reativa para separar a lógica das views, a UI ficou assim usando o Controller:

class Example extends StatelessWidget {
 final controller = Get.put(ControllerExample());
 @override
 Widget build(BuildContext context) {
   return Column(
     mainAxisAlignment: MainAxisAlignment.center,
     children: [
       SizedBox(
         height: 40.0,
         child: Obx(
           () => Text(
             controller.number.value == 0
                 ? 'Click in the button bellow to generate random number'
                 : "Random number: ${controller.number}",
           ),
         ),
       ),
       ElevatedButton(
         onPressed: controller.handleClickEvent,
         child: Text('Generate a number!'),
       ),
     ],
   );
 }
}

Podemos observar que nosso controller é inicializado assim que nosso Widget é usado.

final controller = Get.put(ControllerExample());

E ao longo da UI usamos o controller para saber o estado da variável number, o que nos traz o mesmo comportamento dos exemplos anteriores, mas na execução é possível ver o funcionamento do Obx utilizado escopar o estado number, assim temos o resultado esperado:

Como podemos ver, o número na AppBar não atualizou! Com o Obx ouvindo o number, apenas a parte que necessitamos atualizar é renderizada novamente.
Para finalizar, imagine que precisamos desse número gerado em outra tela, como faríamos? O Get têm uma sintaxe simples e “meio mágica”, ele consegue identificar o controller, uma vez que instanciado, na memória e assim recuperar todo o contexto e estado com o Get.find.

final ControllerExample controller = Get.find();

Então, em uma segunda tela usaremos o nosso estado number:

class PageThatNeedsNumberOfExample extends StatelessWidget {
 final ControllerExample controller = Get.find();
 
 @override
 Widget build(BuildContext context) {
   return Scaffold(
     appBar: AppBar(
       title: Text('Segunda tela'),
     ),
     body: Container(
       child: Center(
         child: Text(controller.number.value == 0
             ? "Você ainda não gerou um número :)"
             : "O número random foi: ${controller.number}"),
       ),
     ),
   );
 }
}

Antes de qualquer coisa, precisamos de uma navegação para a segunda tela, com o Get podemos usar o Get.to e indicar para qual tela desejamos ir

ElevatedButton(
               child: Text('Next Route'),
               onPressed: () {
                 Get.to(PageThatNeedsNumberOfExample());
               },
             ),

Mas, isso não vai funcionar, pois, o Get não tem conhecimento das rotas que o MaterialApp cria, para isso precisamos indicar qual navigator estamos usando (navigatorKey), e nesse caso usaremos o do Get:

 

class MyApp extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
   return MaterialApp(
     navigatorKey: Get.key,
     title: 'Flutter Demo',
     theme: ThemeData(
       primarySwatch: Colors.blue,
     ),
     home: MyHomePage(title: 'Flutter Demo Home Page'),
   );
 }
}

Pronto! Nosso App funciona e já conseguimos passar o estado adiante, sem muito esforço. Esse é o resultado:

Concluindo, sinta-se livre para testar os diversos gerenciadores de estado que existem, mas não tenha medo do setState, que muitas vezes é demonizado, o Flutter evoluiu bastante desde que o setState causava muitos problemas, obrigado por ler e até uma próxima! 🙂

Aproveite para acompanhar outros posts de tutoriais que temos aqui no blog da Taller. 🔥