👩🏼‍🚀 🤴🏽 🦆 Redux vs MobX sem confusão 🚶🏽 📌 🍈

Nos últimos anos, tenho usado frequentemente o Redux , mas recentemente tenho usado o MobX como uma alternativa ao gerenciamento de estado. As alternativas Redux parecem se transformar naturalmente em uma confusão. As pessoas não têm certeza de qual solução escolher. O problema não é necessariamente Redux vs MobX. Sempre que existe uma alternativa, as pessoas ficam curiosas sobre a melhor forma de resolver seu problema. Estou escrevendo estas linhas para eliminar a confusão em torno das soluções de gerenciamento de estado Redux e MobX.

Sobre o que será este artigo? Primeiro, quero voltar brevemente ao problema que a biblioteca de gerenciamento de estado resolve. No final, tudo ficará bem se você apenas usar this.setState () e this.state no React ou sua variação em outra biblioteca no nível da apresentação ou em um ambiente SPA. Em segundo lugar, continuarei a fornecer uma visão geral das duas soluções, mostrando consistência e diferenças. Por último, mas não menos importante, se você já possui um aplicativo que funcione com o MobX ou o Redux, quero falar sobre a refatoração de uma biblioteca de estado para outra.

Conteúdo:

Que problema resolvemos?

Todo mundo quer ter gerenciamento de estado no aplicativo. Mas que problema isso resolve para nós? A maioria das pessoas começa com um aplicativo pequeno e já implementa uma biblioteca de gerenciamento de estado. Todo mundo está falando sobre isso, certo? Restaurado! MobX! Mas a maioria dos aplicativos não precisa de gerenciamento de estado ambicioso desde o início. Isso é ainda mais perigoso, porque a maioria das pessoas nunca será confrontada com problemas como bibliotecas como Redux ou MobX .

Atualmente, o status quo está construindo um aplicativo front-end com componentes. Os componentes têm um estado interno. Em um aplicativo crescente, o gerenciamento de estado pode se tornar caótico com um estado local, porque:

um componente deve compartilhar o estado com outro componente
um componente deve modificar o estado de outro componente

Em algum momento, fica cada vez mais difícil falar sobre o estado do aplicativo. Isso se torna uma rede suja de objetos de estado e mutações de estado na hierarquia de componentes. Na maioria dos casos, objetos de estado e mutações de estado não estão necessariamente associados a um componente. Eles estão vinculados à sua árvore de componentes e você deve aumentar e diminuir o estado.

A solução, portanto, é apresentar uma biblioteca de gerenciamento de estado, como MobX ou Redux. Ele fornece ferramentas para salvar seu estado, alterar estado e receber atualizações de estado. Você tem um local para pesquisar, um local para alterar e um local para receber atualizações de status. Ele segue o princípio de uma única fonte de verdade.. Isso facilita o raciocínio sobre alterações no seu estado e condições, porque elas se separam dos seus componentes.

Bibliotecas de gerenciamento de estado como Redux e MobX geralmente têm complementos para utilitários, por exemplo, para Angular eles têm angular-redux e mobx-angular para dar acesso aos componentes aos seus estados. Geralmente, esses componentes são chamados de componentes em contêineres ou, para ser mais preciso, componentes relacionados . De qualquer lugar da hierarquia de componentes, você pode acessar o estado e alterá-lo, atualizando seu componente para um relacionado.

Qual é a diferença entre REDUX e MOBX?

Antes de mergulharmos na diferença, quero falar sobre as semelhanças entre o MobX e o Redux.

Ambas as bibliotecas são usadas para controlar o estado em aplicativos JavaScript. Eles não estão necessariamente associados a uma biblioteca como Angular. Eles também são usados em outras bibliotecas, como ReactJs e VueJs.

Se você escolher uma das soluções de gerenciamento de estado, não encontrará um bloqueio de fornecedor. Você pode mudar para outra solução de gerenciamento de estado a qualquer momento. Você pode atualizar do MobX para o Redux ou do Redux para o MobX. Mais tarde vou mostrar como isso acontece.

Redux projetado por Dan Abramov e Andrew Clark é um derivado da arquitetura Flux. Ao contrário do Flux, ele usa um repositório em vários para manter o estado. Além disso, em vez de um expedidor, ele usa funções puras para alterar o estado. Se você não está familiarizado com o fluxo e é novo no gerenciamento de estado, não se preocupe com o último parágrafo.

Redux é influenciado pelos princípios de programação funcional (FP). O FP pode ser feito em JavaScript, mas muitas pessoas têm um background orientado a objetos, como Java, e têm dificuldade em aceitar os princípios da programação funcional em primeiro lugar. Isso depois explica por que o MobX pode ser mais fácil de aprender como iniciante.

Como o Redux inclui programação funcional, ele usa funções puras .

Uma função pura é uma função que recebe entrada, retorna saída e não possui outras dependências além das mesmas funções. Essa função sempre produz a mesma saída com a mesma entrada e não tem efeitos colaterais. Mais detalhes

(state, action) => newState

Seu estado Redux é inalterado . Em vez de mudar, você sempre retorna um novo estado. Você não executa mutações de estado e não depende de referências a objetos.


//     Redux,     
function addAuthor(state, action) {
  return state.authors.push(action.author);
}
//       
function addAuthor(state, action) {
  return [ ...state.authors, action.author ];
}

E por último, mas não menos importante, no Redux idiomático, seu estado é normalizado , como em um banco de dados. As entidades se referem uma à outra apenas por ID . Essa é a melhor prática. Embora nem todos o façam, você pode usar uma biblioteca como o normalizr para atingir um estado normalizado. O estado normalizado permite manter um estado e entidades simples como uma única fonte de verdade .

{
  post: {
    id: 'a',
    authorId: 'b',
    ...
  },
  author: {
    id: 'b',
    postIds: ['a', ...],
    ...
  }
}

Em comparação, o MobX de Michel Weststratt é influenciado não apenas pela programação orientada a objetos, mas também pela programação reativa. Envolve seu estado em objetos observáveis. Assim, você tem todos os recursos do " Observable " em seu estado. Os dados podem ter setters e getters simples, mas observáveis permitem que você receba atualizações após alterações nos dados.

No Mobx, seu status é volátil . Dessa forma, você altera o estado diretamente:

function addAuthor(author) {
  this.authors.push(author);
}

Além disso, as organizações permanecem em uma estrutura de dados aninhada (profundamente) uma em relação à outra. Você não normaliza sua condição. A condição permanece desnormalizada e incorporada.

{
  post: {
    id: 'a',
    ...
    author: {
      id: 'b',
      ...
    }
  }
}

Um repositório versus vários

No Redux, você armazena todo o seu estado em um repositório global ou em um estado global . Um único objeto de estado é sua única fonte de verdade. Por outro lado, numerosas caixas de velocidades permitem alterar um estado imutável.

Em comparação, o MobX usa vários repositórios. Como os redutores Redux, você pode aplicar a separação e a conquista por nível técnico, domínio etc. Você pode armazenar seus objetos de domínio em repositórios separados, mas também pode controlar o status de exibição em seus repositórios. No final, você coloca o estado mais apropriado para seu aplicativo.

Tecnicamente, você também pode ter vários repositórios no Redux. Ninguém obriga a usar apenas um. Mas este não é um caso de uso anunciado do Redux. O uso de vários repositórios é contrário às práticas recomendadas. No Redux, você deseja ter um repositório que responde através de seus redutores a eventos globais.

Como é a implementação?

No Redux, adicionar a configuração de um aplicativo a um estado global requer as seguintes linhas de código.

const initialState = {
  users: [
    {
      name: 'Alex'
    },
    {
      name: 'Nik'
    }
  ]
};
// reducer
function users(state = initialState, action) {
  switch (action.type) {
  case 'USER_ADD':
    return { ...state, users: [ ...state.users, action.user ] };
  default:
    return state;
  }
}
// action
{ type: 'USER_ADD', user: user };

No MobX, o armazenamento gerencia apenas o subestado (como o redutor no Redux controla o subestado), mas você pode alterar diretamente o estado. A anotação @observable permite observar alterações de estado.

class userStore{
@observable users = [
    {
      name: 'Nikita'
    }
  ];
}

Agora você pode chamar userStore.users.push (user); na cópia da loja. No entanto, recomenda-se que as mutações de estado sejam mais explícitas por meio da ação.

class userStore{
@observable users = [
    {
      name: 'Nikita'
    }
  ];
}
@action addUser = (user) => {
    this.users.push(user);
  }

Você pode aplicá-lo estritamente configurando o MobX com o configure ({empceActions: true}) ;. Agora você pode alterar seu estado chamando userStore.addUser (user); na cópia da loja.

Você viu como atualizar o estado no Redux e no MobX. No Redux, seu estado é somente leitura . Você só pode alterar o estado com ações explícitas . Por outro lado, no MobX, o estado inclui leitura e escrita. Você pode alterar o estado diretamente sem usar ações, mas pode selecionar ações explícitas usando a configuração enforceActions.

Curva de aprendizado do estado de reação

O Redux e o MobX são usados principalmente em aplicativos React. Mas essas são bibliotecas de gerenciamento de estado independentes que podem ser usadas em qualquer lugar sem o React. Suas bibliotecas de interação facilitam combiná-las com componentes angulares. Estes são react -redux para React + Redux e mobx-react para React + MobX . Mais tarde, explicarei como usar os dois na árvore de componentes Angular.

Em discussões recentes, aconteceu que as pessoas discutiram sobre a curva de aprendizado no Redux. Isso geralmente acontecia no contexto do React: as pessoas começaram a aprender o React e já queriam usar o gerenciamento de estado com o Redux. A maioria das pessoas afirma que o React e o Redux possuem uma boa curva de aprendizado, mas ambos podem ser esmagadores. Portanto, o MobX será uma alternativa, porque é mais adequado para iniciantes.

No entanto, eu sugeriria uma abordagem diferente para os novos usuários do React aprenderem sobre gerenciamento de estado no ecossistema do React. Comece a aprender Reaja com seus próprios recursos locais de gerenciamento de estado nos componentes. Em um aplicativo React, você primeiro aprende sobre os métodos do ciclo de vida do React e entende como gerenciar estados locais com setState () e this.state. Eu recomendo esse caminho de aprendizado. Caso contrário, você será rapidamente dominado pelo ecossistema React. No final, ao longo do caminho, você perceberá que gerenciar o estado (interno) dos componentes se torna complicado.

Redux ou MobX para iniciantes?

Familiarizando-se com os componentes Angular e o gerenciamento interno de estado, você pode escolher uma biblioteca de gerenciamento de estado para resolver seu problema. Depois de usar as duas bibliotecas, eu diria que o MobX pode ser muito conveniente para iniciantes. Já vimos que o MobX precisa de menos código, embora use algumas notas mágicas que ainda não precisamos conhecer.
Com o MobX, você não precisa estar familiarizado com a programação funcional. Termos como imutabilidade ainda podem ser estrangeiros.

— , JavaScript. , , - , , MobX.

Redux

À medida que seu aplicativo cresce, e vários desenvolvedores trabalham nele, considere usar o Redux. Por natureza, ele se compromete a usar ações explícitas para mudar de estado. A ação tem um tipo e carga útil que a caixa de velocidades pode usar para alterar o estado. É muito fácil para a equipe de desenvolvimento falar sobre mudanças de estado dessa maneira.

O Redux fornece uma arquitetura inteira para gerenciamento de estado com limitações claras. História de sucesso do Redux .

Outra vantagem do Redux é seu uso no servidor. Como estamos lidando com JavaScript simples, você pode enviar o estado pela rede. A serialização e desserialização de um objeto de estado funcionam imediatamente. No entanto, isso também é possível com o MobX.

O MobX é menos autoconfiante, mas com o configure ({empceActions: true}) você pode aplicar restrições mais precisas, como no Redux. É por isso que eu não diria que você não pode usar o MobX para dimensionar aplicativos, mas o Redux tem uma maneira clara de fazer alguma coisa. A documentação do MobX até diz: " [MobX] não diz como estruturar seu código, onde armazenar estado ou como manipular eventos ". A equipe de desenvolvimento precisaria primeiro criar uma arquitetura de gerenciamento de estado.

Afinal, a curva de aprendizado da gestão estadual não é tão íngreme. Quando repetimos as recomendações, um novato em React primeiro aprenderá como usar setState () e this.state corretamente . Depois de um tempo, você entenderá os problemas de usar apenas setState ()para manter o estado no aplicativo React. Ao procurar uma solução, você encontra bibliotecas de gerenciamento de estado, como MobX ou Redux. Mas qual escolher? Como o MobX é menos autoconfiante, possui um modelo menor e pode ser usado da mesma forma que o setState (), eu recomendaria dar ao MobX uma chance em pequenos projetos. Assim que o aplicativo aumentar de tamanho e aumentar o número de participantes, considere aplicar restrições adicionais no MobX ou dê uma chance ao Redux. Eu gostei de usar as duas bibliotecas. Mesmo se você não usar um deles no final, faz sentido ver uma maneira alternativa de gerenciar o estado.

Últimos pensamentos

Sempre que leio os comentários na discussão entre Redux e MobX, há sempre um comentário: “O Redux tem muito padrão, você deve usar o MobX. Consegui excluir XXX linhas de código ". O comentário pode ser verdade, mas ninguém considera um compromisso. O Redux vem com muitos modelos, como o MobX, porque foi adicionado para restrições de design específicas. Isso permite que você raciocine sobre o estado do seu aplicativo, mesmo que ele esteja em uma escala maior. Toda a cerimônia associada ao tratamento do estado não é justa.

A biblioteca Redux é bem pequena. Na maioria das vezes, você lida apenas com objetos e matrizes JavaScript simples.. Isso está mais próximo do JavaScript básico do que do MobX. No MobX, objetos e matrizes são agrupados em objetos observáveis que ocultam a maior parte do modelo padrão. Ele é construído sobre abstrações ocultas nas quais a mágica ocorre, mas é mais difícil entender os mecanismos básicos. O Redux facilita falar sobre isso com JavaScript simples. Isso facilita o teste e a depuração do aplicativo.

Além disso, você precisa pensar novamente sobre de onde viemos no SPA. Muitas estruturas de uma página e bibliotecas de aplicativos tiveram os mesmos problemas de gerenciamento de estado que foram resolvidos usando um modelo de fluxo abrangente. Redux é o sucessor dessa abordagem.

No MobX, ele está novamente se movendo na direção oposta. Novamente, começamos a modificar o estado diretamente, sem tirar proveito da programação funcional. Para algumas pessoas, isso se aproxima novamente da ligação de dados bidirecional. Depois de algum tempo, as pessoas podem encontrar novamente os mesmos problemas antes que uma biblioteca de gerenciamento de estado, como o Redux, apareça. O gerenciamento de estado está espalhado pelos componentes e termina em desordem.

Enquanto no Redux você tem uma cerimônia estabelecida para preparar as coisas, o MobX é menos autoconfiante. Mas seria sensato aceitar a melhor experiência MobX. As pessoas precisam saber como organizar a gestão do estado para melhorar seus argumentos sobre isso. Caso contrário, as pessoas tendem a mudar de estado diretamente nos componentes.

Ambas as bibliotecas são ótimas. Embora o Redux já esteja bem estabelecido, o MobX está se tornando uma alternativa viável ao gerenciamento de estado.

Mais recursos

Comparação de Michel Weststratt - criador do
MobX

Redux vs MobX sem confusão