Passar do Redux para o MobX

Porque é que estamos aqui?

Mais cedo ou mais tarde, passá-lo-emos para o MobX tal como fizemos com as outras aplicações. Foi por isso que decidi dar uma vista de olhos rápida. Não haverá assim tanto código aqui e creio que já ouviram falar de Redux. Vamos começar.

O que é o Redux?

Tal como referido em redux.js.org, é "um estado previsível do contentor para Aplicações JS." Foi criado por Dan Abramov e Andrew Clark em 2015.
Pode ser descrito por 3 princípios:

1. Ponto único de verdade - o estado é mantido num único armazém,
2. O estado é só de leitura - não pode alterar diretamente o estado, deve emitir uma ação para o fazer,
3. As alterações são efectuadas com funções puras - por definição, as funções puras devolvem sempre os mesmos resultados para determinados parâmetros, podem ser sempre executadas e não têm efeitos secundários.

O que é o MobX?

Não é surpresa nenhuma, MobX é também uma biblioteca para gestão de estados, que aplica de forma transparente a programação reactiva funcional (TFRP) para a tornar simples e escalável. À semelhança da biblioteca anterior, a sua filosofia é descrita em 3 pontos:
1. Simples - código minimalista, sem caldeiras e sem necessidade de ferramentas especiais para o utilizar,
2. Renderização optimizada sem esforço - garante que todos os cálculos são bem optimizados e não é necessário fazê-lo manualmente,
3. Liberdade arquitetónica - a implementação é livre e pode ser utilizada sem qualquer estrutura de IU.

Comparação entre MobX e Redux

Aprendizagem

React é conhecido pela sua grande carga de trabalho na configuração inicial. Não se pode negligenciar isso. Especialmente quando se tem uma aplicação maior com muitos redutores e acções, provavelmente já se decidiu manter os tipos de ação como constantes nas cadeias de caracteres, o que é uma boa abordagem, mas depois há ainda mais código! Felizmente, o Kit de ferramentas Redux está a ganhar popularidade e atualmente recomenda-se que se escreva Redux lógica. Se me perguntarem, estou a gostar! Ainda assim, há muito para aprender, mas a configuração básica simples com o Toolkit dá conta do recado.

Quando olhei para o Documentação MobXEu era como uma criança que aterrou acidentalmente numa fábrica de chocolate. Estava a ver os exemplos e não parava de perguntar como é que aquilo podia funcionar, mas funciona e aparentemente bem. Mas talvez lidar com todos os redutores, ações, middlewares e outras coisas faça com que seja tão fácil ficar fascinado por outra coisa. No entanto, se você está familiarizado com OOP, MobX será natural para si. Há muito menos codificação inicial e muitas coisas acontecem nos bastidores, pelo que, na maioria dos casos, não precisa de se preocupar com elas.

Estrutura de dados - o que é que está dentro do estado?

Em Reduxtemos de utilizar primitivos, arrays, ou simplesmente JS objectos como dados para o nosso estado.
Além disso, existe uma prática comum quando se armazena dados em arrays, que é a de normalizá-los por questões de performance. Infelizmente, mesmo com as funções auxiliares do Redux's Toolkit (e.g, createEntityAdapter) que continua a acrescentar código adicional.

Em MobXNo artigo "Propriedades", criamos propriedades, objectos inteiros, arrays, Mapas e Conjuntos observável. Sim, as primitivas não são mencionadas aqui porque os seus valores em JS são imutáveis e, por isso, devem ser tratados de forma diferente. Tudo o que precisa de saber se optar por um observável é que ele envolverá a primitiva em "uma caixa" e o getter e setter do valor real estarão disponíveis via .get() e .set(newValue) respetivamente ver observable.box(value)

importar { observable, autorun } de "mobx"

const cityName = observable.box("Vienna") // o mesmo que observable("Vienna")

autorun(() => {
    console.log(cityName.get())
})
// Imprime: 'Viena'

cityName.set("Amesterdão")
// Imprime: 'Amesterdão'

Não há necessidade de normalização dos dados, uma vez que MobX observável` clona o objeto, torna-o observável e, portanto, garante que todas as alterações sejam refletidas no armazenamento assim que atualizarmos qualquer uma das propriedades observáveis.

Localização dos dados - armazém(s)

Temos uma única fonte de verdade em Redux. Ao manter o estado num único local, garantimos que os dados não são duplicados em toda a aplicação e torna-se mais fácil depurá-los.

MobX encoraja, de facto, a existência de pelo menos dois armazenamentos separados, um para o estado da IU e um ou mais para o estado do domínio. Essa separação permite que nós para reutilizar o domínio em diferentes aplicações.

Porque não estamos limitados a JS objectos simples, parece natural criar as suas próprias classes para objectos de domínio específicos, como sugerem os autores. Aqui, Mobx brilha para aqueles que gostam de programação orientada para objectos. É possível ter métodos, controlar o que deve ser observável ou não. Além disso, podemos combinar vários armazenamentos e partilhar as referências.

Imutável e Mutável

Redux exige que a atualização do estado não sofre mutação o estado original. Por isso, se quisermos adicionar um novo item a um array existente, precisamos de devolver uma nova instância em vez de apenas adicionar esse item ao atual.

function todoReducer(state = [], action) {
    // aqui criamos uma nova matriz e utilizamos um operador de dispersão para manter os valores antigos
    return [
      ...estado,
     action.payload
    ]
}

Depois, em MobXpodemos alterar as propriedades observáveis, aqui: o todos matriz. Repare que alteramos a matriz original em addTodo

classe ObservableTodoStore {
  todos = [];

  construtor() {
    makeObservable(this, {
      todos: observable,
      addTodo: ação,
    });
    autorun(() => console.log(this.todos.length))
  }


  addTodo(task) {
    //aqui estamos apenas empurrando o novo item para o array existente!
    this.todos.push({
      task: task,
      completed: false,
    });
  }

}

const observableTodoStore = new ObservableTodoStore();
observableTodoStore.addTodo("Alguma coisa difícil de fazer");

Além disso, podemos até atualizar diretamente o tudo e veremos que execução automática será disparado (ele notará uma mudança na matriz observável de todos).

observableTodoStore.todos.push("Alguma outra tarefa difícil");

// O que é mais interessante, apenas quando actualizas a propriedade to-do em particular
// o MobX avisará (enquanto estiver no modo estrito) que você não deve fazer isso diretamente
observableTodoStore.todos[1].task = ("Talvez algo mais fácil");

Depuração

Pessoalmente, gosto muito do Chrome Extensão Redux DevTools. Permite-lhe dar uma vista de olhos rápida ao estado da sua aplicação e tem boas capacidades para ir e voltar para cada alteração ao estado (viagem no tempo!). Tudo isto é possível devido ao princípio de que não se altera o estado anterior.

A camada adicional de abstração para o armazenamento torna o processo de depuração mais difícil. O Extensão MobX para o Chrome parece-me tão pesado, especialmente se comparado com a experiência anterior, mas talvez precise de algum tempo para me habituar.

Mas temos, por exemplo, o execução automática função de rastreio que provavelmente utilizará muito quando começar a utilizar o MobX e que pretende verificar quando o estado muda. É necessário ter em atenção que a função apenas registará as alterações que observar. Isso é determinado quando a função é executada pela primeira vez. MobX irá subscrever todos os observáveis que foram lidos durante a primeira invocação e será ativado sempre que estes forem alterados.

Popularidade

Quando se olha para a popularidade, o Redux prevalece aqui. Próximo 4 milhões de transferências do npm por semana em comparação com 450k para MobX. Além disso, o número de contribuidores (~870 > 270) e de estrelas (57k > 24k) no repositório do GitHub para cada biblioteca mostra que o Redux é uma marca bem conhecida.

Por outro lado, Relatório sobre o estado da JS 2020 mostra que a satisfação de os utilizar é quase do mesmo nível, pelo que não o ajudará a decidir qual deles escolher para a sua próxima viagem. projeto.

A satisfação neste gráfico foi descrita como "voltaria a utilizar / (voltaria a utilizar + não voltaria a utilizar)"

Conclusão

Não há vencedores neste concurso... ainda! Aliás, não houve concurso nenhum 😉 Penso que ambas as bibliotecas estão a fazer um excelente trabalho ao cumprirem a sua tarefa básica, que é a de ter um estado de gestão sólido no seu Aplicação JS . Vou precisar de mais tempo para ver como funciona o dia a dia com MobX difere de Redux e para que casos o poderia recomendar.

Por enquanto, posso dizer que já estou sentindo falta da "viagem no tempo" das DevTools do Redux, mas por outro lado, definir um estado com MobX parece tão simples e o código escrito parece muito mais legível.

No entanto, tenho muita curiosidade em saber como é que o observável trata do desempenho, pois sempre que vejo alguma magia, pergunto-me quanto dos recursos do meu PC (quer seja tempo de CPU, memória ou unidade) são utilizados e quão eficiente é. Essa será definitivamente a minha próxima fase de investigação.

Espero voltar a contactá-lo com explicações muito interessantes sobre a forma como pode resolver problemas específicos com MobX. Até lá!