🧙 👯 🧖 Redux vs MobX sans confusion 😇 🚵🏾 🧑🏽‍🤝‍🧑🏼

Ces dernières années, j'ai souvent utilisé Redux , mais récemment, j'utilise MobX comme alternative à la gestion des états. Les alternatives Redux semblent se transformer naturellement en désordre. Les gens ne savent pas quelle solution choisir. Le problème n'est pas nécessairement Redux vs MobX. Chaque fois qu'il existe une alternative, les gens sont curieux de savoir comment résoudre au mieux leur problème. J'écris ces lignes pour éliminer la confusion autour des solutions de gestion d'état Redux et MobX.

De quoi parlera cet article? Tout d'abord, je veux revenir brièvement sur le problème résolu par la bibliothèque de gestion d'état. Au final, tout ira bien si vous utilisez simplement this.setState () et this.state dans React ou sa variation dans une autre bibliothèque de niveau présentation ou dans un environnement SPA. Deuxièmement, je continuerai à vous donner un aperçu des deux solutions, en montrant la cohérence et les différences. Enfin et surtout, si vous avez déjà une application qui fonctionne avec MobX ou Redux, je veux vous parler de la refactorisation d'une bibliothèque d'état à une autre.

Contenu:

Quel problème résolvons-nous?

Tout le monde veut avoir une gestion d'état dans l'application. Mais quel problème cela résout-il pour nous? La plupart des gens commencent par une petite application et implémentent déjà une bibliothèque de gestion d'état. Tout le monde en parle, non? Redux! MobX! Mais la plupart des applications n'ont pas besoin d'une gestion d'état ambitieuse dès le départ. C'est encore plus dangereux car la plupart des gens ne seront jamais confrontés à des problèmes tels que des bibliothèques telles que Redux ou MobX .

Le statu quo est en train de créer une application frontale avec des composants. Les composants ont un état interne. Dans une application croissante, la gestion de l'État peut devenir chaotique avec un État local, car:

un composant doit partager l'état avec un autre composant
un composant doit modifier l'état d'un autre composant

À un moment donné, il devient de plus en plus difficile de parler de l'état de l'application. Cela devient une toile sale d'objets d'état et de mutations d'état dans votre hiérarchie de composants. Dans la plupart des cas, les objets d'état et les mutations d'état ne sont pas nécessairement associés à un composant. Ils sont liés via votre arborescence de composants et vous devez augmenter et diminuer l'état.

La solution consiste donc à introduire une bibliothèque de gestion des états telle que MobX ou Redux. Il vous donne des outils pour enregistrer votre état, changer d'état et recevoir des mises à jour d'état. Vous avez un endroit pour rechercher, un endroit pour changer et un endroit pour recevoir les mises à jour de statut. Il suit le principe d'une seule source de vérité.. Cela facilite la réflexion sur les changements de votre état et de vos conditions, car ils se séparent de vos composants.

Les bibliothèques de gestion des états telles que Redux et MobX ont souvent des modules complémentaires pour les utilitaires, par exemple, pour Angular, ils ont angular-redux et mobx-angular pour donner accès à l'état à vos composants. Souvent, ces composants sont appelés composants conteneurisés ou, pour être plus précis, composants connexes . De n'importe où dans votre hiérarchie de composants, vous pouvez accéder à l'état et le modifier en mettant à jour votre composant vers un composant connexe.

Quelle est la différence entre REDUX et MOBX?

Avant de plonger dans la différence, je veux vous parler des similitudes entre MobX et Redux.

Les deux bibliothèques sont utilisées pour contrôler l'état dans les applications JavaScript. Ils ne sont pas nécessairement associés à une bibliothèque comme Angular. Ils sont également utilisés dans d'autres bibliothèques telles que ReactJs et VueJs.

Si vous choisissez l'une des solutions de gestion d'état, vous ne rencontrerez pas de verrouillage de fournisseur. Vous pouvez à tout moment passer à une autre solution de gestion des états. Vous pouvez mettre à niveau MobX vers Redux ou de Redux vers MobX. Plus tard, je vous montrerai comment cela se produit.

Redux conçu par Dan Abramov et Andrew Clark est un dérivé de l'architecture Flux. Contrairement à Flux, il utilise un référentiel sur plusieurs pour maintenir l'état. De plus, au lieu d'un répartiteur, il utilise des fonctions pures pour changer d'état. Si vous n'êtes pas familier avec le flux et que vous êtes nouveau dans la gestion des états, ne vous inquiétez pas du dernier paragraphe.

Redux est influencé par les principes de la programmation fonctionnelle (FP). La FP peut être effectuée en JavaScript, mais beaucoup de gens viennent d'un arrière-plan orienté objet, comme Java, et ont du mal à accepter les principes de la programmation fonctionnelle en premier lieu. Cela explique plus tard pourquoi MobX peut être plus facile à apprendre en tant que débutant.

Étant donné que Redux inclut une programmation fonctionnelle, il utilise des fonctions pures .

Une fonction pure est une fonction qui reçoit une entrée, renvoie une sortie et n'a pas d'autres dépendances que les mêmes fonctions. Une telle fonction produit toujours la même sortie avec la même entrée et n'a aucun effet secondaire. Plus de détails

(state, action) => newState

Votre état Redux est inchangé . Au lieu de muter, vous retournez toujours un nouvel état. Vous n'effectuez pas de mutations d'état et ne dépendez pas des références d'objet.


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

Enfin, dans Redux idiomatique, votre état est normalisé , comme dans une base de données. Les entités ne se réfèrent les unes aux autres que par id . C'est la meilleure pratique. Bien que tout le monde ne le fasse pas, vous pouvez utiliser une bibliothèque comme normalizr pour atteindre un tel état normalisé. L'état normalisé vous permet de maintenir un état plat et des entités comme une source unique de vérité .

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

En comparaison, le MobX de Michel Weststratt est influencé non seulement par la programmation orientée objet, mais aussi par la programmation réactive. Il enveloppe votre état dans des objets observables. Ainsi, vous avez toutes les fonctionnalités de " Observable " dans votre état. Les données peuvent avoir des paramétreurs et des getters simples, mais observables vous permettent de recevoir des mises à jour après les modifications des données.

Dans Mobx, votre statut est volatile . De cette façon, vous changez directement l'état:

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

De plus, les organisations restent dans une structure de données (profondément) imbriquée les unes par rapport aux autres. Vous ne normalisez pas votre état. La condition reste dénormalisée et intégrée.

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

Un référentiel contre plusieurs

Dans Redux, vous stockez tous vos états dans un référentiel global ou dans un état global . Un seul objet d'état est votre seule source de vérité. De nombreuses boîtes de vitesses lui permettent en revanche de changer d'état inchangé.

En comparaison, MobX utilise plusieurs référentiels. Comme les réducteurs Redux, vous pouvez appliquer la séparation et la conquête par niveau technique, domaine, etc. Vous pouvez stocker vos objets de domaine dans des référentiels distincts, mais vous pouvez également contrôler l'état d'affichage dans vos référentiels. Au final, vous placez l'état le plus approprié pour votre application.

Techniquement, vous pouvez également avoir plusieurs référentiels dans Redux. Personne ne vous oblige à en utiliser un seul. Mais ce n'est pas un cas d'utilisation annoncé de Redux. L'utilisation de plusieurs référentiels va à l'encontre des meilleures pratiques. Dans Redux, vous voulez avoir un référentiel qui répond via ses réducteurs aux événements globaux.

À quoi ressemble l'implémentation?

Sur Redux, l'ajout de la configuration d'une application à un état global nécessite les lignes de code suivantes.

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 };

Dans MobX, le stockage ne gère que le sous-état (car le réducteur dans Redux contrôle le sous-état), mais vous pouvez directement changer l'état. L'annotation @observable vous permet d'observer les changements d'état.

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

Vous pouvez maintenant appeler userStore.users.push (user); sur la copie du magasin. Cependant, il est recommandé que les mutations d'état soient plus explicites par l'action.

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

Vous pouvez l'appliquer strictement en configurant MobX avec configure ({empceActions: true}) ;. Vous pouvez maintenant changer votre état en appelant userStore.addUser (user); sur la copie du magasin.

Vous avez vu comment mettre à jour l'état sur Redux et MobX. Dans Redux, votre état est en lecture seule . Vous ne pouvez changer d'état qu'avec des actions explicites . En revanche, dans MobX, l'état inclut la lecture et l'écriture. Vous pouvez muter l'état directement sans utiliser d'actions, mais vous pouvez sélectionner des actions explicites à l'aide de la configuration enforceActions.

Courbe d'apprentissage de l'état de réaction

Redux et MobX sont principalement utilisés dans les applications React. Mais ce sont des bibliothèques de gestion d'état autonomes qui peuvent être utilisées partout sans React. Leurs bibliothèques d'interaction facilitent leur combinaison avec des composants angulaires. Il s'agit de react-redux pour React + Redux et mobx-react pour React + MobX . Plus tard, je vais expliquer comment utiliser les deux dans l'arborescence des composants angulaires.

Lors de récentes discussions, il est arrivé que les gens se disputent sur la courbe d'apprentissage dans Redux. Cela s'est souvent produit dans le contexte de React: les gens ont commencé à apprendre React et voulaient déjà utiliser la gestion des états avec Redux. La plupart des gens affirment que React et Redux ont eux-mêmes une bonne courbe d'apprentissage, mais les deux peuvent être accablants. Par conséquent, MobX sera une alternative, car il convient mieux aux débutants.

Cependant, je suggérerais une approche différente pour les nouveaux utilisateurs de React pour en savoir plus sur la gestion des états dans l'écosystème React. Commencez à apprendre React avec vos propres fonctionnalités de gestion d'état locales dans les composants. Dans une application React, vous apprenez d'abord les méthodes du cycle de vie React et vous comprenez comment gérer les états locaux avec setState () et this.state. Je recommande fortement ce parcours d'apprentissage. Sinon, vous serez rapidement submergé par l'écosystème React. En fin de compte, vous vous rendrez compte que la gestion de l'état (interne) des composants devient compliquée.

Redux ou MobX pour les débutants?

En vous familiarisant avec les composants angulaires et la gestion d'état interne, vous pouvez choisir une bibliothèque de gestion d'état pour résoudre votre problème. Après avoir utilisé les deux bibliothèques, je dirais que MobX peut être très pratique pour les débutants. Nous avons déjà vu que MobX a besoin de moins de code, bien qu'il utilise des notes magiques que nous n'avons pas encore besoin de connaître.
Avec MobX, vous n'avez pas besoin de vous familiariser avec la programmation fonctionnelle. Des termes tels que l'immuabilité peuvent encore être étrangers.

— , JavaScript. , , - , , MobX.

Redux

À mesure que votre application s'agrandit et que plusieurs développeurs y travaillent, vous devriez envisager d'utiliser Redux. Par nature, il s'engage à utiliser des actions explicites pour changer d'état. L'action a un type et une charge utile que la boîte de vitesses peut utiliser pour changer d'état. Il est très facile pour l'équipe de développement de parler des changements d'état de cette manière.

Redux vous fournit une architecture complète pour gérer l'état avec des limitations claires. Histoire de réussite de Redux .

Un autre avantage de Redux est son utilisation côté serveur. Comme nous traitons avec du JavaScript simple, vous pouvez envoyer un état sur le réseau. La sérialisation et la désérialisation d'un objet d'état fonctionnent immédiatement. Cependant, cela est également possible avec MobX.

MobX est moins sûr de lui, mais avec configure ({empceActions: true}), vous pouvez appliquer des restrictions plus précises, comme dans Redux. C'est pourquoi je ne dirais pas que vous ne pouvez pas utiliser MobX pour faire évoluer des applications, mais Redux a un moyen clair de faire quelque chose. La documentation MobX dit même: " [MobX] ne vous dit pas comment structurer votre code, où stocker l'état ou comment gérer les événements ." L'équipe de développement devra d'abord créer une architecture de gestion d'état.

Après tout, la courbe d'apprentissage de la gestion de l'État n'est pas si raide. Lorsque nous répétons les recommandations, un novice de React apprendra d'abord à utiliser correctement setState () et this.state . Après un certain temps, vous comprendrez les problèmes d'utilisation de setState ()pour maintenir l'état dans l'application React. Lorsque vous recherchez une solution, vous rencontrez des bibliothèques de gestion d'état telles que MobX ou Redux. Mais lequel choisir? Étant donné que MobX est moins sûr de lui, a un modèle plus petit et peut être utilisé de la même manière que setState (), je recommanderais de donner à MobX une chance dans les petits projets. Dès que l'application grandit et augmente le nombre de participants, vous devriez envisager d'appliquer des restrictions supplémentaires dans MobX ou donner une chance à Redux. J'ai aimé utiliser les deux bibliothèques. Même si vous n'utilisez pas l'un d'eux à la fin, il est logique de voir une autre façon de gérer l'État.

Dernières pensées

Chaque fois que je lis les commentaires dans la discussion Redux vs MobX, il y a toujours un commentaire: « Redux a trop de standard, vous devriez utiliser MobX à la place. J'ai pu supprimer XXX lignes de code . " Le commentaire est peut-être vrai, mais personne ne considère un compromis. Redux est livré avec de nombreux modèles comme MobX car il a été ajouté pour des contraintes de conception spécifiques. Cela vous permet de raisonner sur l'état de votre application, même si elle est à plus grande échelle. Toute la cérémonie associée au traitement de l'État n'est pas seulement.

La bibliothèque Redux est assez petite. La plupart du temps, vous ne traitez qu'avec de simples objets et tableaux JavaScript.. C'est plus proche du JavaScript vanille que de MobX. Dans MobX, les objets et les tableaux sont enveloppés dans des objets observables qui masquent la plupart du modèle standard. Il est construit sur des abstractions cachées dans lesquelles la magie se produit, mais il est plus difficile de comprendre les mécanismes de base. Redux permet d'en parler plus facilement avec un simple JavaScript. Cela facilite le test et le débogage de l'application.

De plus, vous devez repenser à nos origines au SPA. Un tas de frameworks à page unique et de bibliothèques d'applications ont eu les mêmes problèmes de gestion d'état qui ont finalement été résolus à l'aide d'un modèle de flux complet. Redux est le successeur de cette approche.

Dans MobX, il se déplace à nouveau dans la direction opposée. On recommence à muter l'état directement, sans profiter de la programmation fonctionnelle. Pour certaines personnes, cela se rapproche à nouveau de la liaison de données bidirectionnelle. Après un certain temps, les gens peuvent à nouveau rencontrer les mêmes problèmes avant qu'une bibliothèque de gestion d'état telle que Redux apparaisse. La gestion des états est dispersée entre les composants et se termine par un encombrement.

Alors que sur Redux, vous avez une cérémonie établie pour configurer les choses, MobX est moins sûr de lui. Mais il serait sage d'accepter la meilleure expérience MobX. Les gens doivent savoir comment organiser la gestion de l'État afin d'améliorer leurs arguments à ce sujet. Sinon, les gens ont tendance à changer d'état directement dans les composants.

Les deux bibliothèques sont super. Bien que Redux soit déjà bien établi, MobX devient une alternative viable à la gestion des états.

Davantage de ressources

comparaison de Michel Weststratt - créateur de
MobX

Redux vs MobX sans confusion