Gerenciamento de estado — BLoC
Este provavelmente, será um artigo muito curto, primeiro porque há que esclarecer que o BLoC é mais um padrão que um gestor de estado de concreto, este pode ser combinado com outra abordagens de gerenciamento de estado. Apenas isso!
Mas ok! O que é o BLoC concretamente? Descobrimos isso mais adiante…
Este artigo faz parte de uma série de 5 artigos que vão abordar vários padrões de gerenciamento de estado.
- State Management — Introdução
- State Management — Provider
- State Management — Bloc (este artigo)
- State Management — Redux
- State Management — Mobx
BLoC
O Bloc facilita a separação da apresentação da lógica do negócios tornando seu código rápido, fácil de testar e reutilizável.
BLoC ou Business Logic Component é um padrão recomendado pelos desenvolvedores da Google para gestão da aplicação, especialmente gerenciamento de estado usando o conceito Singleton muito utilizado em backend de modo a oter apenas uma instância de cada objecto e ir actualizando sempre que necessário. A grande particularidade do BLoC é a segregação do código para a lógica do negócio e as widgets (views) como foi abordado quando se falava de Streams.
Mas e quem vai querer usar o BLoC??? Bom, imagina o exemplo do prédio mais uma vez com o guarda, a secretária e o executivo. Na verdade quem vai interagir directamente com o visitante (a mudança no artigo anterior) é o executivo os restantes estão apenas para fazer verificações, ou seja, possuem a lógica do negócio para que o visitante realmente tenha acesso ao executivo. Agora imagina que para além de organizada a empresa é realmente grande possui vários executivos/departamentos e pode receber vários visitantes em horários que nalgum momento se sobreponham! Aí seria necessário contratar outros guardas e secretários? Talvez sim, talvez não mas na maioria dos caso não é o caso pois estas são tarefas que facilmente podem ser realizadas pelos mesmos indivíduos, então vamos pelo não. Agora nós temos por exemplo 3 departamentos/executivos distintos com reuniões de uma hora cada, a primeira no dep. A as 11h30, a segunda no dep.B as 12h00 e a última as 12h15, o secretário e o guarda já têm conhecimento e permitirão a entrada destes nos seus devidos horários, e lembrem-se são o mesmo guarda e secretário mas os departamentos a que serão encaminhados já não. Em linhas gerais isso quer dizer que nós temos a mesma lógica de negócio associada a diferentes views/partes de nossa aplicação, daí a necessidade de se segregar o código de modo a permitir acesso da informação onde ela é devida sem precisar repetir a lógica do negócio para cada view.
Como disse no início, podemos combinar o BLoC com outras abordagens de gerenciamento de estado, como o provider. Prova é o facto de termos usado o mesmo exemplo para explicar ambos conceitos sem mudar nenhum facto!
Uma nota importante é perceber que no processo todo de identificar uma mudança, notificar, executar de acordo acontecem alguns eventos que modificam o estado e as mudanças são sempre acompanhadas de dados que irão influenciar na mudança a partir do dado de entrada até nos fornecer outros na saída…
, se estiver confuso atente aos próximos conceitos e se não estiver continue acompanhando.
Events
Os eventos representam exactamente eventos, de entrada, ou seja, são a resposta imediata da aplicação a uma interação do utilizador ou quando uma view é carregada. No nosso caso de estudo temos como evento o visitante apresentar-se ao portão, por exemplo.
States
Obviamente que estes eventos deverão resultar em alguma saída. Imaginemos então que o visitante já apresentou-se e foi notificada sua chegada, é importante agora que o executivo a recebê-lo deve organizar o espaço para recebê-lo, baseando-se no carácter da reunião (que já foi sabido quando este apresentou-se). Analogamente, imaginemos em uma aplicação de concreto onde o utilizador pressiona no botão para alterar a cor do tema da aplicação e de seguida a aplicação realmente muda de cor, de acordo com a cor escolhida pelo utilizador, a UI foi actualizada baseando-se numa acção específica do utilizador.
Transitions
Mas em algum momento a aplicação fica sem um estado? Não! Todos os estados da aplicação são, bom… estados. A mudança de um estado para o outro é chamada de transição ou como indicado em inglês transition. Então, antes nós tínhamos por exemplo zero visitantes e o executivo prosseguia com suas actividades de rotina e logo que o número de visitantes altera e este é notificado as suas actividades alteram. Quanto a cor, antes a app tinha uma cor por mais que fosse branca, ela altera seu estado no momento que o utilizador pede outra cor e isto pode ser controlado usando o padrão BLoC.
Streams
BLoC é essencialmente usado com recurso a streams, o que significa que é importante ter algum conhecimento acerca. Streams, pra quem não sabe ainda, é simplesmente uma sequência de dados assíncronos. Posto isto, há que perceber então que o BLoC é composto por um stream de events que resulta em um stream de states, ele é, portanto, o cérebro de toda aplicação.
BlocDelegate
São vários eventos, vários estados e consequentemente várias transições acontecendo em uma única aplicação, pois então, a abordagem para gerir todos estes elementos é o BlocDelegate que é responsável por gerir todas as transições.
Para entender melhor o BLoC, veja o artigo sobre o RxDart, com exemplo explícito!
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!!!
