Explication détaillée des exemples de sélection de Redux et Mobx

Redux et Mobx sont tous deux des modèles de flux de données populaires en ce moment. Il semble que la communauté ne sache naturellement pas quoi choisir pour remplacer Redux. Le développeur ne sait pas quelle solution choisir. Ce problème ne se limite pas à Redux et Mobx. Chaque fois qu’un choix existe, les gens se demandent quelle est la meilleure façon de résoudre un problème. Ce que j'écris maintenant est de résoudre la confusion entre les deux bibliothèques de gestion d'état Redux et Mobx.

La plupart des articles utilisent React pour présenter l'utilisation de Mobx et Redux. Mais dans la plupart des cas, vous pouvez remplacer React par Angular, Vue ou autre chose.

Début 2016, j'ai écrit une application assez volumineuse en utilisant React + Redux. Lorsque j’ai découvert que Mobx pouvait être utilisé comme alternative à Redux, j’ai pris le temps de refactoriser l’application de Redux vers Mobx. Maintenant, je peux les utiliser très confortablement et expliquer leur utilisation.

De quoi va parler cet article ? Si vous ne prévoyez pas de lire un article aussi long (TLDR : trop long, je n'ai pas lu (veuillez apporter votre propre échelle pour voir ce lien)), vous pouvez consulter la table des matières. Mais je souhaite vous donner plus de détails : tout d'abord, je souhaite passer brièvement en revue les problèmes que la bibliothèque de gestion d'État résout pour nous. Après tout, nous pouvons faire tout aussi bien si nous utilisons uniquement setState() lors de l'écriture de React ou si nous utilisons setState() et des méthodes similaires lors de l'écriture d'autres frameworks SPA. Deuxièmement, je parlerai brièvement des similitudes et des différences entre eux. Troisièmement, je montrerai aux débutants dans l'écosystème React comment apprendre la gestion de l'état de React. Rappel amical : avant de vous plonger dans Mobx et Redux, veuillez d'abord utiliser setState(). Enfin, si vous possédez déjà une application utilisant Mobx ou Redux, je vais vous expliquer davantage comment refactoriser l'une de ces bibliothèques de gestion d'état à l'autre.

Table des matières

Quel problème essayons-nous de résoudre ?

Quelle est la différence entre Mobx et Redux ?

Courbe d'apprentissage de la gestion de l'état React

Essayer une autre solution de gestion de l'état ?

Réflexions finales

Quel problème essayons-nous de résoudre ?

Tout le monde veut utiliser la gestion d'état dans ses applications. Mais quel problème cela résout-il pour nous ? De nombreuses personnes ont introduit une bibliothèque de gestion d'état lors du démarrage d'une petite application. Tout le monde parle de Mobx et de Redux, n'est-ce pas ? Mais la plupart des applications ne nécessitent pas au départ une gestion d’état à grande échelle. Cela peut même être dangereux car ces personnes ne pourront pas rencontrer les problèmes que les bibliothèques comme Mobx et Redux sont censées résoudre.

La situation actuelle est d'utiliser des composants pour créer une application front-end. Les composants ont leur propre état interne. Par exemple, dans React, l'état local mentionné ci-dessus est géré à l'aide de this.state et setState(). Mais la gestion de l'état local peut rapidement devenir déroutante dans une application volumineuse car :

Un composant doit partager l'état avec un autre composant

Un composant a besoin Après avoir changé l'état d'un autre composant

dans une certaine mesure, il deviendra de plus en plus difficile de déduire l'état de l'application. Cela devient une application déroutante avec de nombreux objets d'état modifiant l'état de chacun au niveau des composants. Dans la plupart des cas, les objets d'état et les modifications d'état n'ont pas besoin d'être liés à un composant. Lorsque vous promouvez des états, ils sont disponibles via l'arborescence des composants.

La solution est donc d'introduire une bibliothèque de gestion d'état, comme Mobx ou Redux. Il fournit des outils pour enregistrer l'état, modifier l'état et mettre à jour l'état quelque part. Vous pouvez obtenir l'état à partir d'un seul endroit, le modifier à partir d'un seul endroit et obtenir ses mises à jour à partir d'un seul endroit. Il suit le principe d’une source unique de données. Cela nous permet de déduire plus facilement les valeurs d'état et les modifications d'état car elles sont découplées de nos composants.

Les bibliothèques de gestion d'état comme Redux et Mobx sont généralement accompagnées d'outils, tels que React-redux et mobx-react utilisés dans React, qui permettent à vos composants d'obtenir un état. Généralement, ces composants sont appelés composants conteneurs, ou plus précisément composants connectés. Tant que vous mettez à niveau votre composant vers un composant connecté, vous pouvez obtenir et modifier l'état n'importe où dans la hiérarchie des composants.

Quelle est la différence entre Mobx et Redux ?

Avant de plonger dans les différences entre Redux et Mobx, je veux parler des similitudes entre eux.

Les deux bibliothèques sont utilisées pour gérer l'état des applications JavaScript. Ils n'ont pas besoin d'être regroupés avec React, ils peuvent également être utilisés avec d'autres bibliothèques comme AngularJs et VueJs. Mais ils s’intègrent très bien aux idées de React.

Si vous choisissez l’une des solutions de gestion étatique, vous ne vous sentirez pas enfermé. Parce que vous pouvez à tout moment passer à une autre solution. Vous pouvez passer de Mobx à Redux ou de Redux à Mobx. Je vais vous montrer comment procéder ci-dessous.

Le Redux de Dan Abramov est dérivé de l'architecture flux. Différent du flux, Redux utilise un seul magasin au lieu de plusieurs magasins pour enregistrer l'état. De plus, il utilise des fonctions pures au lieu de répartiteurs pour modifier l'état. Si vous n'êtes pas familier avec le flux et n'avez pas été exposé à la gestion de l'état, ne le faites pas. être dupé par ce contenu.

Redux est influencé par les principes de FP (Functional Programming). FP peut être utilisé en JavaScript, mais de nombreuses personnes ont une formation en langages orientés objet, tels que Java. Au début, ils ont du mal à s’adapter aux principes de la programmation fonctionnelle. C'est pourquoi Mobx peut être plus simple pour les débutants.

Puisque Redux adopte FP, il utilise des fonctions pures. Une fonction pure qui prend une entrée et renvoie une sortie et n'a aucune autre dépendance. Une fonction pure a toujours le même résultat avec les mêmes entrées et n'a aucun effet secondaire.

(state, action) => newState

Votre état Redux est immuable, vous devez toujours renvoyer un nouvel état plutôt que de modifier l'état d'origine. Vous ne devez pas effectuer de modifications d'état ou de changements basés sur des références d'objet.

// don't do this in Redux, because it mutates the array
function addAuthor(state, action) {
 return state.authors.push(action.author);
}
// stay immutable and always return a new object
function addAuthor(state, action) {
 return [ ...state.authors, action.author ];
}

Enfin, dans le langage de Redux, le format d'état est standardisé comme une base de données. Les entités se réfèrent les unes aux autres uniquement par leur identifiant, ce qui constitue une bonne pratique. Bien que tout le monde ne le fasse pas, vous pouvez également utiliser normalizr pour normaliser l'état. L'état normalisé vous permet de maintenir un état plat et de conserver les entités comme source unique de données.

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

Mobx de Michel Weststrate est influencé par la programmation orientée objet et la programmation réactive. Il enveloppe l'état dans un objet observable, de sorte que votre état possède toutes les capacités d'Observable. Les données d'état ne peuvent avoir que des setters et des getters ordinaires, mais observable nous permet d'obtenir des valeurs mises à jour lorsque les données changent.

L'état de Mobx est mutable, vous modifiez donc l'état directement :

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

Sinon, l'entité d'état reste des structures de données imbriquées se relier les uns aux autres. Vous n'êtes pas obligé de standardiser l'état, mais de les conserver imbriqués.

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

Magasin unique vs magasins multiples

Dans Redux, vous mettez tout l'État dans un plan global magasin. Cet objet de magasin est votre source de données unique. D'un autre côté, plusieurs réducteurs vous permettent de modifier l'état immuable.

Mobx, quant à lui, utilise plusieurs magasins. Semblable aux réducteurs Redux, vous pouvez diviser et conquérir à un niveau technique ou dans un domaine. Peut-être souhaitez-vous stocker vos entités de domaine dans différents magasins tout en gardant le contrôle de l'état dans la vue. Après tout, vous configurez l'état pour que votre application paraisse raisonnable.

Techniquement parlant, vous pouvez également utiliser plusieurs magasins dans Redux. Personne ne vous oblige à utiliser un seul magasin. Mais ce n'est pas l'utilisation recommandée de Redux. Parce que cela va à l’encontre des meilleures pratiques. Dans Redux, votre magasin unique répond aux mises à jour via des événements globaux sur les réducteurs.

Comment utiliser ?

Vous devez suivre le code ci-dessous pour apprendre à utiliser Redux. Tout d'abord, ajoutez un tableau utilisateur à l'état global. Vous pouvez voir que j'utilise l'opérateur de propagation d'objet pour renvoyer un nouvel objet. Vous pouvez également utiliser Object.assign() pour opérer sur des objets immuables dans ES6 (à l'origine ES5, en fait ES6).

const initialState = {
 users: [
 {
 name: 'Dan'
 },
 {
 name: 'Michel'
 }
 ]
};
// 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 };

Vous devez utiliser dispatch({ type: 'USER_ADD', user: user });

Dans Mobx, un store ne gère qu'un seul sous-état (tout comme le réducteur qui gère le sous-état dans Redux), mais vous pouvez modifier l'état directement.

@observable nous permet d'observer les changements d'état.

class UserStore {
 @observable users = [
 {
 name: 'Dan'
 },
 {
 name: 'Michel'
 }
 ];
}

Nous pouvons maintenant appeler la méthode d'instance de magasin : userStore.users.push(user);. Il s’agit d’une bonne pratique, même si l’utilisation d’actions pour modifier l’état est plus explicite.

class UserStore {
 @observable users = [
 {
 name: 'Dan'
 },
 {
 name: 'Michel'
 }
 ];
 @action addUser = (user) => {
 this.users.push(user);
 }
}

Dans Mobx, vous pouvez ajouter useStrict() pour forcer l'utilisation d'une action. Vous pouvez maintenant appeler la méthode sur l'instance du magasin : userStore.addUser(user); pour modifier votre état.

Vous avez vu comment mettre à jour l'état dans Redux et Mobx. Ils sont différents. L'état dans Redux est en lecture seule. Vous ne pouvez utiliser que des actions explicites pour modifier l'état. Dans Mobx, l'état est lisible et inscriptible. Vous pouvez modifier l'état directement sans utiliser d'actions. peut utiliserStrict() pour utiliser des actions explicites.

Courbe d'apprentissage de la gestion de l'état React

Les applications React utilisent largement Redux et Mobx. Mais ce sont des bibliothèques de gestion d’état indépendantes et peuvent être utilisées n’importe où sauf React. Leur bibliothèque d'interopérabilité nous permet de connecter facilement les composants React. réagissez-redux pour Redux + React et mobx-react pour MobX + React. J'expliquerai plus tard comment ils sont utilisés dans l'arborescence des composants React.

Au cours de discussions récentes, les gens ont débattu de la courbe d'apprentissage de Redux. Cela se produit généralement dans le scénario suivant : Débutants React qui souhaitent utiliser Redux pour la gestion de l'état. La plupart des gens pensent que React et Redux ont eux-mêmes des courbes d’apprentissage élevées et que la combinaison des deux peut devenir incontrôlable. Une alternative est Mobx car il convient mieux aux débutants.

然而，我会建议 React 的初学者一个学习状态管理的新方法。先学习React 组件内部的状态管理功能。在 React 应用，你首先会学到生命周期方法，而且你会用 setState() 和 this.state 解决本地的状态管理。我非常推荐上面的学习路径。不然你会在 React 的生态中迷失。在这条学习路径的最后，你会认识到组件内部管理状态难度越来越大。毕竟那是 The Road to learn React 书里如何教授 React 状态管理的方法。

现在我们重点讨论 Redux 和 Mobx 为我们解决了什么问题？它俩都提供了在组件外部管理应用状态的方法。state 与组件相互解耦，组件可以读取 state ，修改 state ，有新 state 时更新。这个 state 是单一数据源。

现在你需要选择其中一个状态管理库。这肯定是要第一时间解决的问题。此外，在开发过相当大的应用之后，你应该能很自如使用 React 。

初学者用 Redux 还是 Mobx ?

一旦你对 React 组件和它内部的状态管理熟悉了，你就能选择出一个状态管理库来解决你的问题。在我两个库都用过后，我想说 Mobx 更适合初学者。我们刚才已经看到 Mobx 只要更少的代码，甚至它可以用一些我们现在还不知道的魔法注解。
用 Mobx 你不需要熟悉函数式编程。像“不可变”之类的术语对你可能依然陌生。函数式编程是不断上升的范式，但对于大部分 JavaScript 开发者来说是新奇的。虽然它有清晰的趋势，但并非所有人都有函数式编程的背景，有面向对象背景的开发者可能会更加容易适应 Mobx 的原则。

注：Mobx 可以很好的在 React 内部组件状态管理中代替 setState，我还是建议继续使用 setState() 管理内部状态。但链接文章很清楚的说明了在 React 中用 Mobx 完成内部状态管理是很容易的。

规模持续增长的应用

在 Mobx 中你改变注解过的对象，组件就会更新。Mobx 比 Redux 使用了更多的内部魔法实现，因此在刚开始的时候只要更少的代码。有 Angular 背景的会觉得跟双向绑定很像。你在一个地方保存 state ，通过注解观察 state ，一旦 state 修改组件会自动的更新。

Mobx 允许直接在组件树上直接修改 state 。

// component
<button onClick={() => store.users.push(user)} />

更好的方式是用 store 的 @action 。

// component
<button onClick={() => store.addUser(user)} />
// store
@action addUser = (user) => {
 this.users.push(user);
}

用 actions 修改 state 更加明确。上面也提到过，有个小功能可以强制的使用 actions 修改 state 。

// root file
import { useStrict } from 'mobx';
useStrict(true);

这样的话第一个例子中直接修改 store 中的 state 就不再起作用了。前面的例子展示了怎样拥抱 Mobx 的最佳实践。此外，一旦你只用 actions ，你就已经使用了 Redux 的约束。

在快速启动一个项目时，我会推荐使用 Mobx ，一旦应用开始变得越来越大，越来越多的人开发时，遵循最佳实践就很有意义，如使用明确的 actions 。这是拥抱 Redux 的约束：你永远不能直接修改 state ，只能使用 actions 。

迁移到 Redux

一旦应用开始变得越来越大，越来越多的人开发时，你应该考虑使用 Redux 。它本身强制使用明确的 actions 修改 state 。action 有 type 和 payload 参数，reducer 可以用来修改 state 。这样的话，一个团队里的开发人员可以很简单的推断 state 的修改。

// reducer
(state, action) => newState

Redux 提供状态管理的整个架构，并有清晰的约束规则。这是 Redux 的成功故事。

另一个 Redux 的优势是在服务端使用。因为我们使用的是纯 JavaScript ，它可以在网络上传输 state 。序列化和反序列化一个 state 对象是直接可用的。当然 Mobx 也是一样可以的。

Mobx 是无主张的，但你可以通过 useStrict() 像 Redux 一样使用清晰的约束规则。这就是我为什么没说你不能在扩张的应用中使用 Mobx ，但 Redux 是有明确的使用方式的。而 Mobx 甚至在文档中说：“ Mobx 不会告诉你如何组织代码，哪里该存储 state 或 怎么处理事件。”所以开发团队首先要确定 state 的管理架构。

状态管理的学习曲线并不是很陡峭。我们总结下建议：React 初学者首先学习恰当的使用 setState() 和 this.state 。一段时间之后你将会意识到在 React 应用中仅仅使用 setState() 管理状态的问题。当你寻找解决方案时，你会在状态管理库 Mobx 或 Redux 的选择上犹豫。应该选哪个呢？由于 Mobx 是无主张的，使用上可以和 setState() 类似，我建议在小项目中尝试。一旦应用开始变得越来越大，越来越多的人开发时，你应该考虑在 Mobx 上实行更多的限制条件或尝试使用 Redux 。我使用两个库都很享受。即使你最后两个都没使用，了解到状态管理的另一种方式也是有意义的。

尝试另一个状态管理方案？

你可能已经使用了其中一个状态管理方案，但是想考虑另一个？你可以比较现实中的 Mobx 和 Redux 应用。我把所有的文件修改都提交到了一个Pull Request 。在这个 PR 里，项目从 Redux 重构成了 Mobx ，反之亦然，你可以自己实现。我不认为有必要和 Redux 或 Mobx 耦合，因为大部分的改变是和其他任何东西解耦的。

你主要需要将 Redux 的 Actions、Action Creator、 Action Types、Reducer、Global Store 替换成 Mobx 的 Stores 。另外将和 React 组件连接的接口 react-redux 换成 mobx-react 。presenter + container pattern 依然可以执行。你仅仅还要重构容器组件。在 Mobx 中可以使用 inject 获得 store 依赖。然后 store 可以传递 substate 和 actions 给组件。Mobx 的 observer 确保组件在 store 中 observable 的属性变化时更新。

import { observer, inject } from 'mobx-react';
...
const UserProfileContainer = inject(
 'userStore'
)(observer(({
 id,
 userStore,
}) => {
 return (
 <UserProfile
 user={userStore.getUser(id)}
 onUpdateUser={userStore.updateUser}
 />
 );
}));

Redux 的话，你使用 mapStateToProps 和 mapDispatchToProps 传递 substate 和 actions 给组件。

import { connect } from 'react-redux';
import { bindActionCreators } from 'redux';
...
function mapStateToProps(state, props) {
 const { id } = props;
 const user = state.users[id];
 return {
 user,
 };
}
function mapDispatchToProps(dispatch) {
 return {
 onUpdateUser: bindActionCreators(actions.updateUser, dispatch),
 };
}
const UserProfileContainer = connect(mapStateToProps, mapDispatchToProps)(UserProfile);

这有一篇怎样将 Redux 重构为 Mobx指南。但就像我上面说过的，反过来一样也是可以的。一旦你选择了一个状态管理库，你会知道那并没有什么限制。它们基本上是和你的应用解耦的，所以是可以替换的。

最后思考

每当我看 Redux vs Mobx 争论下的评论时，总会有下面这条：“Redux 有太多的样板代码，你应该使用 Mobx，可以减少 xxx 行代码”。这条评论也许是对的，但没人考虑得失，Redux 比 Mobx 更多的样板代码，是因为特定的设计约束。它允许你推断应用状态即使应用规模很大。所以围绕 state 的仪式都是有原因的。

Redux 库非常小，大部分时间你都是在处理纯 JavaScript 对象和数组。它比 Mobx 更接近 vanilla JavaScript 。Mobx 通过包装对象和数组为可观察对象，从而隐藏了大部分的样板代码。它是建立在隐藏抽象之上的。感觉像是出现了魔法，但却很难理解其内在的机制。Redux 则可以简单通过纯 JavaScript 来推断。它使你的应用更简单的测试和调试。
另外，我们重新回到单页应用的最开始来考虑，一系列的单页应用框架和库面临着相同的状态管理问题，它最终被 flux 模式解决了。Redux 是这个模式的成功者。

Mobx 则又处在相反的方向。我们直接修改 state 而没有拥抱函数式编程的好处。对一些开发者来说，这让他们觉得像双向绑定。一段时间之后，由于没有引入类似 Redux 的状态管理库，他们可能又会陷入同样的问题。状态管理分散在各个组件，导致最后一团糟。

使用 Redux，你有一个既定的模式组织代码，而 Mobx 则无主张。但拥抱 Mobx 最佳实践会是明智的。 开发者需要知道如何组织状态管理从而更好的推断它。不然他们就会想要直接在组件中修改它。

两个库都非常棒。Redux 已经非常完善，Mobx 则逐渐成为一个有效的替代。

相关推荐：

react-redux中connect的装饰器用法

如何理解 redux

在React中使用Redux的实例详解

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!