Minha decepção com o BLoC

Jacob Moura
Dec 27, 2019 · 9 min read

Esses títulos chamativos estão fazendo sucesso em 2019, então que tal finalizar com um?

É dificil fazer esse tipo de texto sem machucar alguem, então se doer em você, entenda que o remédio as vezes é amargo.
Desde já venho apresentar meus pontos, mas isso não significa que sou um semi-deus irrefutável, mas por favor, leia todo ele antes de me xingar nos comentários.


Um Pouco de Contexto

Trabalho com Flutter desde o começo, vi que era uma grande oportunidade para pessoas que desejariam entrar na área, pois esse framework consegue unir facilidade com qualidade e tudo isso cross-platform.
Comecei então a buscar parceiros e falar sobre o meu interesse de fazer o Brasil ser referência nessa tecnologia. Infelizmente vários só pensavam em dinheiro e não em ajudar as pessoas. No bom português, arregacei as mangas e comecei a trabalhar aqui no Brasil com um blog chamado "Flutterando".

Desde então, com meu jeito pateta de ser comecei a ajudar, meu ideal foi (e sempre será) dar oportunidade para as pessoas entrarem no mercado de trabalho, e com isso em mente acabei encontrando uma galera com esse mesmo ideal, e a partir dai nasceu a comunidade Flutterando.

Tentava-mos ensinar tudo que ficava disponível lá fora (na gringa) em português. Óbvio que nos deparamos com vários tipos de pessoas, e também passamos muito sufoco juntos. Desde acusações infundadas a processos judiciais por clones indevidos (ZapZap huehue).
Pagamos o preço e agora colhemos os frutos, hoje a Flutterando é conhecida como a maior comunidade brasileira independente apoiada pelo Google.


Ai escolhemos o BLoC

Tive a oportunidade de conhecer vários tipos de pessoas pelo Brasil inteiro e também tive acesso a um grande acervo de dúvidas sobre Flutter ecoadas pelas nossas redes sociais e canais de comunicação, e eu posso garantir para vocês, cerca de 70% dessas dúvidas são sobre BLoC.
Mas primeiro temos que voltar um pouco no tempo para entender como chegamos no BLoC (Eu terminei The Witcher na Netflix, então estou me sentindo um contador de histórias :)

Quando começamos a realmente colocar o Flutter em produção, tivemos alguns problemas de peformance usando o setState, naquele momento ainda não se falava de BLoC. Consegui entregar meus dois primeiros aplicativos usando apenas setState.
Depois disso, veio uma necessidade incomum para a época. Eu precisava atualizar a AppBar do meu Aplicativo estando em um widget filho.

Eu comecei a bolar maneiras de chamar um setState global, e dai conheci o maravilhoso mundo das Streams.
Arrisco a dizer que a API de Streams é a melhor coisa do Dart, e tudo nessa linguagem é Stream.
A partir dai criei um StreamController em uma classe Global(Singleton) e usei o StreamBuilder para atualizar o botão na minha AppBar quando clicasse em um widget filho.
Fiquei maravilhado com o que eu acabara de fazer, além disso percebi que ele só reconstruia uma parte do código.

Pode ser estranho ter me acostumado tão rápido com as Stream e tudo ser tão intuitivo para mim, mas vale lembrar um ponto importante da minha história, (EU SOU DESENVOLVEDOR ANGULAR) Estados e Fluxos para esse framework são tudo, e comecei a aprender que para o Flutter também seria.

Nessa época até comecei até duvidar do Flutter por precisar gerenciar estados na aplicação, pois ele era vendido como "nativo", mas isso foi bobeira minha e hoje a gerência de estado está indo muito bem nas plataformas Android com o Kotlin e no iOS com o Swift.

Em paralelo a isso, algo veio forte no nosso grupinho de Whats…(quero dizer ZupZup). Uma forma de gerênciar estados apresentado pelo Google. Foi aquele bafafa.
Quando olhei para aquele formato de código, era bem semelhante ao que eu fazia, só que sem o Getter e Setter. Também tinha uma coisa fundamental naquele padrão de código que realmente me chamou a atenção, o DISPOSE!

SIM, descobri que os StreamControllers da vida podem ficar ativo até depois do aplicativo fechar, e que impactaria todo o sistema operacional além de complicações na concorrência do próprio app.
Eu lembro que quando essa ficha caiu eu pensei.. (HOLY SHIT!!!), estava usando uma BOMBA e não sabia.

Depois de muito falar e mostrar gráficos que eu particulamente odeio porque prefiro a prática, veio o nome desse padrão:
Bussines Logic Component, ou BLoC.

A ideia erá apenas separar o código da regra de negócio do código responsável pela visualização (os Widgets).
E não vi problema nenhum nisso, alias, aquela salada que era meus arquivos .dart era de lascar.
Então, como usava meus Singletons com StreamController como um EventBus(Coisa que usava no Android pra conseguir transmitir dados entre as telas), resolvi abraçar e usar esse padrão.

Então lá foi eu, "bunitamente" adaptar meu código todo para um lindo e maravilhoso BLoC. E o dispose? Eu resolvi colocando um StatefulWidget antes do MaterialApp e no dispose() do estado matava meu BLoC. (Aqui comecei também a pensar no conceito de Providers).
Mas logo começaram os problemas…


Como ensinar BLoC para a comunidade?

Ta ai uma pergunta que me remoeu durante dias, eu simplesmente não conseguia achar uma forma de explicar BLoC de uma maneira que valeria a pena todo o esforço em ter mais um arquivo, e também mais linhas de código para os StreamControllers e seus getters e setters além do dispose().
Quem conhece o canal do Flutterando sabe o quanto já falei sobre BLoC, mas parecia que nunca era o suficiente.
De tempos em tempos aparecia algum sujeito que dizia: "Aprenda BLoC de uma vez por todas!" e também não conseguia nada.

Durante esse periodo tentei várias formas de ensino, percebi o que faltava para a comunidade eleger de vez o BLoC como seu Gerênciador de Estado Default, faltava ENDOSSO.

A partir dai comecei a procurar pessoas que falavam sobre o assunto na comunidade, e dei voz a elas para se tornar refência e assim fazer as pessoas abrirem o coração para aprender o padrão BLoC.
Lembre-se, é crucial usar gerência de estado no Flutter e dividir o código para melhor manutenabilidade posteriomente, e isso ajudou o Flutter crescer nas empresas também.

Finalmente as pessoas começaram a aprender BLoC, mas as dúvidas nunca diminuiram, logo sempre ficava com a sensação de que faltava alguma coisa.


Regras

O BLoC estava caminhando na comunidade, mas ai veio as famosas "regrinhas do BLoC", vou lista-las pra você:

  • Não pode passar contexto para o BLoC.
    Era uma necessidade comum visto que o contexto é necessário para chamar uma nova tela ou abrir um Modal, mas algumas pessoas entenderam que ao passar o Context para a classe BLoC ela perdia o seu desacoplamento

Nessa primeira regrinha boba vale ressaltar um ponto:
BLoC originalmente foi pensado para funcionar não só no Flutter, mas também no AngularDart ou em qualquer outro framework posterior que usasse Dart.
Como sabemos, o AngularDart está na UTI, e estamos vivendo um momento em que o Flutter está tomando conta de tudo (web, mobile, desktop e embbed). Então torna essa regra IRRELEVANTE.

  • BLoC precisa usar Streams para tudo.

Nessa regrinha básica você não poderia criar um arquivo e usar outras formas para gerenciar estado, como por exemplo o ChangeNotifier ou apenas listeners de Closures. Você poderia fazer, mas não seria considerado como BLoC (Quando ouvi isso, inclusive de uma pessoa bem importante, me veio um sentimento de "PQP o que é BLoC então").

  • Você não pode fazer conexão entre BLoCs dentro de um BLoC

Já vi pessoas fazendo isso, e me deu um pouco de pena. Se você tiver dois BLoCs e eles precisam "conversar", então você precisaria abrir um listener no initState da View para tramitar as informações.
Isso se dá pelo mesmo motivo, deixar o BLoC desacoplado.

Tem várias outras regrinhas, mas eu estou ficando com raiva só de lista-las aqui, então isso já é o suficiente.

Como se já não bastasse, a comunidade entrou em conflito por causa dessas e de outras regrinhas, fazendo assim nascer vários tipos de BLoCs, (vou lista-los enquanto sorrio de nervoso).

  • BLoC com RXDART
  • BLoC com package flutter_bloc
  • BLoC com contexto
  • BLoC puro (kkkkkkkkkkkkk)

Em meio a toda essa confusão tentamos colaborar construindo um padrão. Para isso conversamos com o pessoal da Google (que no momento estava apoiando e divulgando o Provider), e também tentamos falar com o Paolo Soares (pseudo-criador do BLoC) mas esse senhor nunca nos respondeu, e nem respondeu ninguém sobre.

Em meio a todos esses fogos, vimos que a comunidade iniciou uma outra thread (bem peculiar) de dúvidas… BLoC vs Provider

Confesso que perdia a cabeça quando alguem vinha me perguntar sobre isso, pois todos nós sabemos que o BLoC é um "padrão" (que era passado boca a boca, porque nunca teve um manifesto) e o Provider é apenas o que o nome diz, um ONLY FUCK PROVEDOR.

Mas isso me abriu os olhos para algo importante, e é uma verdade dificil de se engolir, mas a comunidade nunca gostou do BLoC e estava disposta a enfrentar qualquer outra coisa para fugir dele. O que foi interessante de se assistir.

Você já parou pra pensar o porque do BLoC não fazer sentido para quem está começando?

O BLoC nunca cumpriu seu papel de ajudar a comunidade, e deixou um Flutter um pouco enfadonho. Antes da gente continuar eu quero deixar bem claro o que o BLoC siginifica para mim.

Para mim o BLoC é apenas streams controllers, predispostas em um arquivo separado, porém o ator principal nesse arquivo sempre foi e sempre será o StreamController.
Dito isso, a gente entra na segunda fase dessa história que é quando eu cago para essas regrinhas e crio uma Estrutura de projetos a que passo para a comunidade.
Nessa estrutura a qual falo é feita usando o bloc_pattern(agora flutter_modular) + Slidy, que dispõem os arquivos de forma muito semelhante ao Angular (lembra que sou Dev Angular né).

A partir de agora o BLoC para mim passa a ser algo como um Controller, e assim passo para a comunidade e adivinhem, finalmente as dúvidas diminuiram, o BLoC finalmente havia achado o seu lugar, mas desse jeito o BLoC nunca era um BLoC de verdade.

Com todos os experimentos bem sucedidos com o bloc_pattern + slidy, tendo sua estrutura usada em Projetos enormes, ficou claro a melhor maneira de se trabalhar com Flutter, a melhor gerência de estados é com Stream e não com BLoCs…

Não sei se fez muito sentido isso, mas o que quero dizer é, bastava usar StreamController ou os Subjects do rxdart em um arquivo que ele automaticamente se transformava em um BLoC.
Ou seja, o nome BLoC estava se apropriando de uma coisa que não é dele, todo o ganho foi graças a API de Stream, e todas essas "Regrinhas" só atrapalhou, por isso o BLoC não foi pra frente, porque seus pseudo-criadores deram um nome a algo e desapareceram.

Mesmo assim não quer dizer que usar BLoC vai te trazer alguns problemas, até porque já deve ter percebido que todo o ganho que teve não é graças ao BLoC, mas sim Graças a API Streams!!!

Na medida que deu certo talvez você nunca "usou" o BLoC, o que você usou na verdade foi o Padrão Observer.


Padrões

Como já deve ter entendido, eu não considero mais o BLoC um padrão, no máximo um aliase para Padrão Observer aplicado com a API de Stream.

Eu não posso deixar de citar também que o BLoC pode ser um novo padrão, se melhor documentado e bastante testado, porém hoje, NADA é graças a essa nomeclatura BLoC, e sim a API Streams.

Existe vários padrões de projetos, que foram testados durante anos e estão devidamente documentados, além disso são usados em várias outras linguagens.
Os padrões são categorizados em 3 partes: Criacional, Estrutural e Comportamental. Exemplo de alguns que já deve ter usado:

Singleton -> Criacional
Adapter -> Estrutural
Observer -> Comportamental

Então aqui percebemos o que são essas categorias.
Não há nada de errado em convergir vários padrões para criar um novo, isso é perfeitamente normal, e foi tentado com o BLoC.

O Problema do BLoC é que mesmo usando os padrões já consagrados como o Observer e Rx nunca há um consenso geral sobre o assunto.
Você não pode sair na rua e conversar com um desenvolvedor Java sobre BLoC, ele vai olhar para você e falar: "Maluco pq essa verbosidade"… huehue

E mesmo se o BLoC se consolidar em um padrão, isso não seria agora, pois primeiro teria que haver uma documentação, um manifesto e anos de experiência com essa tecnologia, e nesse quesito, o BLoC é novo ainda.

Minhas Conclusões

Depois desse longo texto você já deve ter entendido meu ponto, mas não me importo em lista-los novamente. Aqui vão os motivos que me fizeram ficar decepcionado com o BLoC.

  • Divergências constante sobre esse tópico.
  • Dificuldade para ensinar na comunidade.
  • Regras sem fundamento que só atrapalham.
  • Dispariedade com outros padrões.
  • Existe coisas melhores hoje em dia…

Sobre esse último tópico, gostaria de revelar que o MobX já suporta totalmente a API Async do Dart (Streams e Futures) e que melhor aplica o Padrão Observer.
Também há uma equipe tentando trazer o redux para Flutter, e será muito bem vindo.


Então é isso pessoal…
Coloque suas críticas e sugestões nos comments abaixo, acredito que deixei bem claro para onde remaremos a Flutterando no próximo ano.

Feliz 2020 e VAMOS SER REFERÊNCIA JUNTOS!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade