Vuex (getters) + Herança Reativa e Prototype
Quem nunca passou por uma situação onde implementava um getter da nossa querida Vuex e sem querer, outro getter já implementado tinha seus valores alterados inexplicavelmente, resultando na quebra dos testes que antes passavam?
Nesse artigo iremos devanear sobre conceitos importantes que acontecem “de baixo dos panos” no meio de todo esse ecossistema de reatividade e elegância que nos permeia, quando desenvolvemos soluções usando a Vuex.
Flux…
A inspiração para criação da Vuex é o Flux, um conceito arquitetural unidirecional onde “sintetizadamente” temos a centralização de um objeto único na aplicação (fazendo analogia a um objeto global) comumente chamado de state. As states são alimentadas pelas mutations e consumidas pelos getters. As mutations por sua vez são disparadas pelos dispatchers.
O conceito de Flux também é utilizado por outros gerenciadores de estados famosos, exemplo Redux do React.
Uma diferença da implementação do conceito Flux na Vuex pro Redux do React seria a a de imutabilidade na state, onde a mutation altera os valores da state e não criam novos.
O que seria imutabilidade? 🤔
O conceito de imutabilidade em computação é a qualidade de não ser capaz de se alterar. É um conceito bastante utilizado hoje em dia na programação funcional, sendo um dos pilares de seu paradigma.
“Então você me diz que é uma qualidade não mudar as coisas? E o U do CRUD?”
Irei colocar dois exemplos de códigos arbitrários, onde incitarei a você leitor indicativos de onde quero chegar.
Os exemplos acima relembram o conceito de ponteiros (referências de memórias), onde o operador de atribuição “=” no primeiro exemplo o abstrai.
Indo mais a fundo em tal devaneio, podemos afirmar que nas linhas 3 e 4 do exemplo 1 os objetos d e c herdam a cadeia de prototypes* do objeto c. Já no exemplo 2, a instância de um novo objeto localizado nas linhas 1 e 2 quebram essa cadeia, tendo referências de memória novas.
Como assim cadeia de prototypes?
Quando te falaram uma vez que javascript é puro objeto, realmente não mentiram 😂.
Se colarmos o código abaixo em um terminal qualquer que tenha interpretador de javascript, teremos os seguintes resultados comentados:
Sendo assim, a cadeia de herança das instâncias (qualquer uma, array, string, objeto) segue esse modelo de Prototype Chain, herdando no mais baixo nível da cadeia o prototype de um objeto, sendo que a recursividade do mesmo encontra-se o valor null.
E aonde você quer chegar?
Com todo esse embasamento teórico resumido, podemos voltar ao problema da introdução desse artigo…
Quando escrevemos getters, comumente derivamos o estado recebido de nossas dependências (sejam states ou getters) para obter resultados precisos.
Um código muito comum encontrado em aplicações que usam Vuex seria:
Quando escrevemos códigos desse tipo, se obtermos o log da constante bug, podemos observar que a mesma herdou os prototypes reativos (implementados por meio da própria Vuex) da dependência stateX, colocando em risco a própria stateX dependendo das modificações que fizermos em bug.
Toda essa herança resultada causa quebras de resultados finais nos escopos, que na realidade não alterou em si o escopo, mas o conteúdo que foi injetado.
Como resolvo isso?
O objetivo desse devaneio todo não é um tutorial sobre algo possível de acontecer em nosso dia a dia (afinal, esse exemplo é totalmente fora de contexto e abstraído), mas sim trazer os conceitos a tona a fim de fazer o leitor entender o que realmente acontece quando implementamos códigos desse tipo.
Porém uma possível solução pra situação acima seria usar o método Arr.map, que também deriva o resultado original retornando um novo array.
Deixei em negrito a palavra novo acima, pois ela incita a imutabilidade anteriormente mencionada.
Conclusão
Passamos por conceitos importantes em programação pra quem utiliza Vuex em seus projetos Vue, entre outros.
Referências Gerais
https://github.com/vuejs/vuex
https://github.com/facebook/flux
https://vuex.vuejs.org/#what-is-a-state-management-pattern
