浅谈前端响应式设计（二）

文 | jinzhixin on 前端

上一篇文章

提到了几种响应式的方案，以及它们的缺点。本文将介绍以及它的一个实现，以及它在处理响应式时相对于上篇博客中的方案的巨大优势（推荐两篇博客对比阅读）。

是一个集合了观察者模式、迭代器模式和函数式的库，提供了基于事件流的强大的异步处理能力，并且已在草案中。本文介绍的是的一个实现，它是ReactiveX众多语言中的版本。

在中，我们可以使用去处理一个单值，使用去处理多个值得情况，使用处理异步的单个值，而则填补了缺失的“异步多个值”。

使用 Rxjs

上文提到使用做响应式处理，在中稍有些不同：

在这里，我们虽然也需要手动释放对事件的订阅，但是得益于的设计，我们不需要像那样去存下回调函数的实例，用于释放订阅，因此我们很容易就可以通过高阶组件解决这个问题。例如：

这样在需要聚合多个数据源时，也不会像那样手动释放资源造成麻烦。同时，在中我们还有专用于聚合数据源的方法：

显然相对于的方式十分高效，同时它相对于也有巨大的优势。在中，我们提到需要聚合多个数据源的时候，采用的方式容易收集到不必要的依赖，使用则不够高效。在中，显然不会有这些问题，可以以很简练的方式声明需要聚合的数据源，同时，得益于设计，我们不需要像一个一个去调用返回的析构，只需要处理每一个返回的：

异步处理

使用操作符去描述各种行为，每一个操作符会返回一个新的，我们可以对它进行后续的操作。例如，使用操作符就可以实现对数据的转换：

之后所有的上都引入了一个方法，接收若干个操作符，方法会返回一个。因此，我们可以很容易配合实现对操作符的按需引入，而不是把整个引入进来：

推荐使用这种写法。

在讨论面向对象的响应式的响应式中，我们提到对于异步的问题，面向对象的方式不好处理。在中我们可以通过操作符处理异步问题，一个异步搜索看起来会是这样：

在处理异步单值时，我们可以使用，而用于处理异步多个值，我们可以很容易把一个转成一个，从而复用已有的异步代码：

接受一个返回的函数作为参数，下游的流就会切到这个返回的。而要聚合多个数据源并做异步处理时：

同时，由于标准制定的是没有方法的，有时候我们要取消异步方法的时候就有些麻烦（主要是为了解决一些并发安全问题）。当上游有新值到来时，会忽略结束已有未完成的然后调用函数返回一个新的，我们只使用一个函数就解决了并发安全问题。当然，我们可以根据实际需要选用、、、等。

而对于时间轴的操作，也有巨大优势。上篇博客中提到当我们需要延时 5 秒做操作时，无论是还是面向对象的方式都力不从心，而在中我们只需要一个操作符即可解决问题：

用 Rxjs 处理数据

在实际开发过程中，事件不能解决所有问题，我们往往会需要存储数据，而被设计成用于处理事件，因此它有很多符合事件直觉的设计。

被设计为懒（）的，当当没有订阅者时，一个流不会执行。对于事件而言，没有事件的消费者那么不执行也不会有问题。而在 GUI 中，订阅者可能是：

由于这个可能不存在，例如路由被切走了，那么我们的事件源就没有了订阅者，他就不会运行。但是我们希望在路由被且走后，后台的数据依然会继续。

对于事件而言，在事件发生之后的订阅者不会受到订阅之前的逻辑。例如在中：

由于是在事件发生后在监听的，不会收到值为的事件。但是这在处理数据的时候会造成麻烦，我们的数据在被卸载（例如路由切走）后丢失。

同时，由于没有提供直接取到内部状态的方法，当我们使用处理数据时，我们不方便随时拿到数据。那有办法解决这个问题，从而使强大抽象能力去赋能数据层呢？

回到。的事件（Action）其实是一个事件流，那么我们就可以很自然地把的事件流融入到流中：

通过这样的封装，redux-observable就能让我们把强大的事件描述和处理能力和结合。我们可以非常方便地根据去处理副作用：

使我们可以结合和。在这里，被视作一个流，相当于，从而得到需要监听的，得益于的设计，我们可以通过监听去完成副作用的处理或者监听数据变化。最后这个流返回一个新的流，会把这个新的流中的出去。由此，我们在使用存储数据的基础上获得了对异步事件的强大处理能力。

----- 技术活动 -----

由中国 MySQL 用户组主办的 ACMUG & CRUG 2018 技术沙龙全国巡演将于2018 年 7 月 21 日 9:30 ～ 17:30在杭州举办，有赞杨奇龙受邀参加分享，分享主题为《有赞数据库服务实践》，介绍从 0 到 1 构建有赞数据库服务体系，了解有赞的数据库自动化系统-ZanDB的演进过程。