flux 【第1304期】聊一聊Redux的前身Flux

前言

抽奖，开心就好，祝大家端午节健康。今天早上看的文章是网易考拉海宝@Gloria提交分享的。

@格洛里亚，前端工程师，网易考拉工作

正文从这里开始~

现在出现了很多国家管理方案，每个方案背后都有理念支持其实现。这些想法不是“空”，而是为解决发展中的各种问题而生的。

接下来，我们将讨论两种流行的状态管理方案，Redux和Mobx。

为了深入了解Redux，不可避免的要谈到它的前身Flux。

概念

在开始本文之前，我们需要了解在使用MV*框架如react.js和vue.js时模型和视图的概念

MVVM的两个概念图。巴布亚新几内亚-3.2kB

完整的交互过程如上图所示。

视野

视图，意思是“视图”，是最终在浏览器上看到的页面元素。

模型

模特，翻译成“模特”，那么……什么是“模特”？看看下面的代码。

& ltdiv>。

& ltp>。{ { a.b } } & lt/p>。

& ltp>。{ { a.c } } & lt/p>。

& ltp>。{ { a.d } } & lt/p>。

& lt/div>。

上面的代码，a.b，a.c，a.d，框架会在这些属性值改变的时候帮助我们生成View。

如果再宏观一点看这个问题，其实可以把对象A看成数据，上面的html代码就是模板，所以我们有这样的理解:框架把数据应用到模板，最后生成View，也就是B过程。

这里，数据+模板是一个模型，称为“模型”。一般来说，模板是固定的，不会动态变化，所以我们实现的大多数交互都是改变数据上属性的过程，示意图中的A过程。

当前发展中的问题

好了，在介绍了Model和View这两个概念之后，说说在这两个抽象层面的开发过程中遇到的问题。

碎片修改

我们互动的基础是操作模型。就拿上面的代码片段来说，操作Model就是修改a . b . a . c .和A.D .所以，操作这个Model就会出现下图所示的情况，修改操作会以“碎片化”的方式存在于整个组件文件的每个角落。

单一数据库模式。巴布亚新几内亚-7kB

有了上面的架构，我们可以勉强控制一些简单的应用场景，但是面对稍微复杂一点的应用场景，我们就被拉伸到极限了。为什么这么说？

这个架构最基本的应用单元是组件，每个组件的Model实际上是对应的dataBase。如果我们想修改某个组件中其他组件的dataBase，我们需要得到这个组件的路由器，但是“得到路由器”并不是那么简单。。根据构件之间的关系，可以分为父子关系、孙儿关系、兄妹关系三种情况，所以会出现以下情况。

多数据库模式。巴布亚新几内亚-23.1kB

为了解决这个问题，Flux的另一个概念来了，dispatcher。

3.请求分销商

通量的调度器其实解决了以上问题。

调度程序对每个组件都是全局的。它可以向所有路由器发送请求。用户不需要知道自己需要请求哪台路由器，让每台路由器自行处理传入的请求。这种抽象实际上将请求视为全局请求，一个请求可以同时操作多个dataBase。

介绍调度员。巴布亚新几内亚-16.7kB

当然调度器不会找到它需要分发给自己的路由器，但是我们需要调用register方法来手动注册路由器。

dispatcher.register；

注册路由器后，直接调用dispatcher的dispatch方法即可，可以发送如下请求:

dispatcher . dispatch；

默认情况下，Flux按照注册顺序将请求放入路由器。如果我们想在发送请求后定制某个路由器的执行顺序呢？Flux提供了waitFor方法。

比如routerA收到请求后希望依次通过routerB和routerC，可以像下面的伪代码一样实现:

让TokenB = dispatcher . register；

让TokenC = dispatcher . register；

让routerA =function{

switch{

case ' ADD _ TODO ':dispatcher . WaitFor；打破；

...

}

};

好的，你必须提前拿到routerB和routerC的令牌，然后依次传入waitFor方法。

4.数据库ˌ资料库

dataBase实际上代表组件的状态。

Flux将路由器和dataBase作为一个整体，将请求分析和数据库修改统一起来存储。

Store.reduce相当于router，而Store。_state相当于dataBase，因此有以下体系结构

店铺架构。巴布亚新几内亚-19kB

最后，Flux采用向外抛出事件的方式，将_state到Model的映射交给用户。

可以调用store.addListener方法，传入回调函数监听_state的变化。

store.addListener= >;{

let state = store . GetState；

...映射到模型的操作...

});标签

Flux的一整套抽象可以在单向数据流的基础上提高应用程序的可维护性和代码的可预测性。然而，全局动作+多商店的架构仍然不能解决面对复杂应用时的复杂数据流问题。虽然waitFor可以满足多个存储接收动作的顺序，但是会使数据流变得复杂，难以维护。

作为Flux的继承者，单店架构实际上避免了上述问题，下面的文章将深入分析如何基于Flux对其架构进行改进。

参考:

流量官方介绍:深度概述

官方仓库:github.com/facebook/flux

关于这篇文章

原文:

https://zhuanlan.zhihu.com/p/38050036

那些前端MVVM框架是怎么诞生的