Redux VS Mobox

最新推荐文章于 2024-07-14 21:56:49 发布

weixin_30849403

最新推荐文章于 2024-07-14 21:56:49 发布

阅读量1.7k

点赞数

文章标签： javascript 前端后端 ViewUI

原文链接：http://www.cnblogs.com/sueing/p/9540595.html

版权

Mobx和Redux都是JavaScript应用状态管理库，都适用于React，Angular，VueJs等框架或库，而不是局限于某一特定UI库。

Redux

要介绍Redux，我们就不得不谈到Flux了:

Flux是Facebook用来开发客户端-服务端web应用程序的应用架构，它更多是一种架构模式，而非一个特定框架。

而Redux更多的是遵循Flux模式的一种实现，是一个JavaScript库，它关注点主要是以下几方面：

Action：一个JavaScript对象，描述动作相关信息，主要包含type属性和payload属性：
1. type：action 类型；
2. payload：负载数据；
Reducer：定义应用状态如何响应不同动作（action），如何更新状态；
Store：管理action和reducer及其关系的对象，主要提供以下功能：
1. 维护应用状态并支持访问状态（getState()）；
2. 支持监听action的分发，更新状态（dispatch(action)）；
3. 支持订阅store的变更（subscribe(listener)）；
异步流：由于Redux所有对store状态的变更，都应该通过action触发，异步任务（通常都是业务或获取数据任务）也不例外，而为了不将业务或数据相关的任务混入React组件中，就需要使用其他框架配合管理异步任务流程，如redux-thunk，redux-saga等；

Mobx

Mobx是一个透明函数响应式编程（Transparently Functional Reactive Programming，TFRP）的状态管理库，它使得状态管理简单可伸缩：

Action：定义改变状态的动作函数，包括如何变更状态；
Store：集中管理模块状态（State）和动作（action）；
Derivation（衍生）：从应用状态中派生而出，且没有任何其他影响的数据，我们称为derivation（衍生），衍生在以下情况下存在：
1. 用户界面；
2. 衍生数据；衍生主要有两种：
  1. Computed Values（计算值）：计算值总是可以使用纯函数（pure function）从当前可观察状态中获取；
  2. Reactions（反应）：反应指状态变更时需要自动发生的副作用，这种情况下，我们需要实现其读写操作；

单一store和多store

store是应用管理数据的地方，在Redux应用中，我们总是将所有共享的应用数据集中在一个大的store中，而Mobx则通常按模块将应用状态划分，在多个独立的store中管理。

JavaScript对象和可观察对象

Redux默认以JavaScript原生对象形式存储数据，而Mobx使用可观察对象：

Redux需要手动追踪所有状态对象的变更；
Mobx中可以监听可观察对象，当其变更时将自动触发监听；

选择Mobx的原因

学习成本少：Mobx基础知识很简单，学习了半小时官方文档和示例代码就搭建了新项目实例；而Redux确较繁琐，流程较多，需要配置，创建store，编写reducer，action，如果涉及异步任务，还需要引入redux-thunk或redux-saga编写额外代码，Mobx流程相比就简单很多，并且不需要额外异步处理库；
面向对象编程：Mobx支持面向对象编程，我们可以使用@observable and @observer，以面向对象编程方式使得JavaScript对象具有响应式能力；而Redux最推荐遵循函数式编程，当然Mobx也支持函数式编程；
模版代码少：相对于Redux的各种模版代码，如，actionCreater，reducer，saga／thunk等，Mobx则不需要编写这类模板代码；

不选择Mobx的可能原因

过于自由：Mobx提供的约定及模版代码很少，这导致开发代码编写很自由，如果不做一些约定，比较容易导致团队代码风格不统一，所以当团队成员较多时，确实需要添加一些约定；
可拓展，可维护性：也许你会担心Mobx能不能适应后期项目发展壮大呢？确实Mobx更适合用在中小型项目中，但这并不表示其不能支撑大型项目，关键在于大型项目通常需要特别注意可拓展性，可维护性，相比而言，规范的Redux更有优势，而Mobx更自由，需要我们自己制定一些规则来确保项目后期拓展，维护难易程度；

无论前端还是后端，遇到问题，大多数时候也许大家总是习惯于推荐已经普遍推广使用的，习惯，熟悉就很容易变成顺理成章的，我们应该更进一步去思考，合适的才是更好的。

当然对于“Redux更规范，更靠谱，应该使用Redux”或”Redux模版太多，太复杂了，应该选择Mobx”这类推断，我们也应该避免，这些都是相对而言，每个框架都有各自的实现，特色，及其适用场景，正比如Redux流程更复杂，但熟悉流程后就更能把握它的一些基础／核心理念，使用起来可能更有心得及感悟；而Mobx简单化，把大部分东西隐藏起来，如果不去特别研究就不能接触到它的核心／基本思想，也许使得开发者一直停留在使用层次。

所以无论是技术栈还是框架。类库，并没有绝对的比较我们就应该选择什么，抛弃什么，我们应该更关注它们解决什么问题，它们解决问题的关注点，或者说实现方式是什么，它们的优缺点还有什么，哪一个更适合当前项目，以及项目未来发展。

转载于:https://www.cnblogs.com/sueing/p/9540595.html