Máquinas de estado, quando usar, por que e para que?
Assim como eu sempre faço um paralelo com a ciência da matéria no Atomic Design, esses termos aí também podem ser paralelizados com o fato de que nós, seres humanos, muitas vezes reagimos de maneiras diferentes conforme os estímulos que recebemos. Nós somos orientados a eventos e por muitas vezes, diante de muitas situações os afetos provocados pelo ambiente onde estamos, alteram nosso estado emocional.
Gerência de estados tem sido um assunto da atualidade, principalmente se você está envolvido com Javascript e toda velocidade do nosso ecossistema gigantesco, com certeza, pelo menos já se deparou com algo sobre.
Esse será o primeiro tópico a ser abordado hoje. Se você ainda não sabe o que é uma máquina de estado ou mesmo se sabe mas ainda não tem usado, chegou a hora de começar a admitir que terá que usar. E já te adianto, é um caminho sem volta.
Em Javascript nós possuímos algumas implementações famosas que gerenciam estados.
A que eu acredito ser a mais conhecida, é a Redux, que se define como uma máquina de estados previsíveis para aplicativos JavaScript. O objetivo dela é te ajudar a escrever aplicações que se comportam de forma consistente, funcionam em diferentes ambientes de desenvolvimento, como clientes, servidores e ambientes nativos que são fáceis de serem testadas. Você pode usar o Redux diretamente com React ou de forma agnóstica em qualquer aplicação JS. O Redux possui uma extensão para o DevTools do Firefox e do Chorme que te permite ‘viajar no tempo’, ou seja, ir pra frente e pra trás nas ações que o usuário fez enquanto usava a aplicação. E isso é super maneiro, além de ser muito útil.
Outra implementação conhecida atualmente é exclusiva para VueJS, a Vuex. Na minha própria concepção, como Vuex é preso e dependente direto de VueJS, a biblioteca pode se tornar mais poderosa e mais completa que Redux por diversos fatores. Ela se define como um padrão de gerenciamento de estados que serve como um centralizador das informações para todos os componentes. Suas regras internas garantem que o estado da aplicação só possa ser mudado de forma previsível. Assim como Redux, Vuex possui uma extensão para o DevTools do Firefox e do Chorme. Além de você ‘viajar no tempo’ da aplicação, você pode exportar e importar estados prévios. Acredite, isso ajuda MUITO durante o debug e no tempo de desenvolvimento de uma grande aplicação. Imagina só que você pode reproduzir uma série de ações do usuário até encontrar um determinado bug, ou que até, não precisa ficar fazendo X interações com a aplicação a cada refresh do navegador.
A terceira mais famosa implementação de gerência de estados (e a mais recente) é a ngRX (que é a junção do Redux com RxJS) e é exclusiva para Angular. A biblioteca elenca suas qualidades começando pelo fato de que o estado é uma estrutura de dados única e imutável, que as ações definem as mudanças no estado, e que as funções responsáveis pelas alterações no estado são puras. Como por baixo do capô dela nós temos o Redux, quem já está acostumado com ela e está trabalhando com Angular, não terá problema algum em usar a biblioteca. Da mesma maneira, você poderá usar a extensão do Redux para o DevTools dos navegadores.
A proposta de todas essas bibliotecas é sempre a mesma. Acho que isso ficou bem claro nas suas definições. Todas elas querem te ajudar a gerenciar o estado da aplicação de forma consistente, pura, funcional, imutável e consequentemente, promover a tal reatividade entre seus componentes. Ou seja, esses caras pegam a responsabilidade das informações de todos os seus componentes e te força a descolar uns dos outros, criando diversos gatilhos para que os dados do seu componente possam ir de um lado para o outro de uma forma única, imutável e direcional.
Tá, mas aí você pode me dizer que até hoje fez suas aplicações com React, Vue ou Angular sem usar nada disso e que todas funcionam muito bem, obrigado. Ok, realmente não posso discordar de você, todas realmente devem funcionar. Gerência de estado não é bala de prata, mas nada é. Porque então devemos usar uma máquina de estado, ou melhor, quando devemos usar?
O primeiro sinal que você precisa identificar é a quantidade de componentes que você tem na sua aplicação, é um número grande? Se você já caiu de cabeça no Atomic Design, nós sabemos que sim, você terá vários componentes. Talvez até um número que nós dois tenhamos vergonha de falar por aí porque pode parecer loucura.
Outro sinal é a ‘árvore genealógica’ que seus componentes formam, por exemplo, quando você tem um componente pai que chama um componente filho, que reage num componente neto e que a interação do usuário provocará uma reação no componente tio! Bizarro isso, né?
Ou até se mesmo assim você conseguir disparar esses eventos todos chamando de trás pra frente o fluxo dos dados, você consegue imaginar a panela de espaguete que está construindo? Esse App, com certeza vai trazer dores algum dia que você precisar desmontar esse castelo de cartas aí.
Outro ponto importante que você precisa pensar é se o seu fluxo de dados está preso a sua interface, a partir do momento que as informações que você tem, são somente as que estão renderizadas na tela, você precisará se esforçar muito mais pra fazer que as informações fluam para que assim novas telas apareçam. Da mesma maneira, se seu estado estiver distribuído somente na sua interface nos componentes já renderizados, a qualquer mudança desse estado, você terá de ‘inundar’ todos os componentes com as alterações para que sua informação chegue no destinatário correto.
É como aqueles hub’s de rede antigos, lembra? (Se você nasceu em 90, e conseguiu acompanhar o começo da internet, com certeza você sabe do que eu tô falando). Esses hub’s simplesmente não sabiam quem eram os computadores ligados a eles e então, eles simplesmente ‘inundavam’ a rede toda e todas as máquinas atrás do destinatário. Consegue imaginar a latência e a lentidão que isso provocava? Pois é, isso acontece nesse seu App gigante aí que ainda não tem gerência de estado isolada dos componentes.
Esse artigo para por aqui, mas continua no episódio dessa semana lá no site do ELEMENCAST. São só 14 minutos de áudio de conteúdo puro! E se você não puder ouvir exatamente agora, você pode pegar o arquivo mp3 e ouvir onde você quiser. Além de poder assinar o feed RSS, ouvir pelo iTunes ou pelo seu app favorito de podcasts 😄
Ah, Todo conteúdo é completamente gratuito e sempre será!
Eu quero instigar sua curiosidade pra que você pesquise junto comigo sobre o assunto e me ajude a fazer este podcast ficar ainda mais legal. Eu também preciso que deixe o seu e-mail lá no site pra você ficar por dentro da newsletter do podcast, eu sempre aviso quem tá lá primeiro quando sai um novo episódio e é claro, preciso da sua colaboração enviando este conteúdo pro seu amigo mais próximo ou até pro seu chefe que tá em dúvida se coloca uma máquina de estado naquele projeto novo da empresa.
Você pode me ajudar também, indo diretamente até o Github do Elemencast e abrindo uma issue sobre o que você quiser, por lá podemos conversar diretamente e você pode baixar qualquer episódio que eu liberar, todos estarão lá, inclusive este.
Uma comunidade forte, é uma comunidade unida que se ajuda.
Muito obrigado até aqui. Até a próxima.
