一场无声的军备竞赛:js响应式编程

近几年来,前端框架层出不穷,我们不禁感叹,不知道未来两年还会有什么新框架出现。这种无力的感叹,究竟是因为前端的想象力太过丰富,人才太多,各自新式花样的东西会冒出来,还是因为有内在的规律?我相信,作为一个历史学系毕业的学生,万事皆有规律,这种规律支配着下一代编程的可能性。

有些人觉得这是玄学,他认为,之所以有这样的规律,是因为那些东西胜出了,胜者为王,历史都是胜利者书写。然而,如果把逻辑反过来,自问,为什么在众多框架中,vue、react如日中天,为什么typescript越来越被接纳?难道是因为他们本身太过优秀?为什么webpack这么火,打包工具不是没有rollup如此优秀,怎么不是它火爆到如此?为什么seajs挂了?

我认为,更多的原因,是因为他们用最恰当的方式解决了当下开发者的痛点

抽象化

而痛点是什么?这就是我们今天要讨论的话题。当下这个时代,前端开发的痛点有两个:1.抽象化;2.同构。抽象化是指将某种原本混杂的概念,抽象为某种逻辑清晰的理念,最成功的,当属“Virtual DOM”。同构,是指写一套代码,在不同端使用,PC、手机、服务器……总之,这两点都是当下已经探索出门路的东西,所以,才有那么多东西围绕这两天冒出来。

其实同构这个痛点解决起来轻松很多,大家都有思路,只是方案不同,京东凹凸实验室做了一个项目,叫Taro,用以实现一套代码,构建出在PC、app、微信小程序等多个平台运行的应用。同构大家都有思路,只是方案还没有完善而已。

但是,抽象化,则更像是一个哲学问题,它要研究,要实验,要有理论支撑,要集大成,要有权威人物发言,要有知名厂商站台。因此,在对前端开发规范、标准、模式等各个方面的竞争,就像一场军备竞赛一样,很多人既不甘心,又不得不使用最流行的框架或规范。

也正是因为这样,我们在感觉到这几年前端领域的混乱的同时,似乎也感觉到另外的东西,前端正在范式化,很多问题都在被解决,虽然有些方案看上去还没有变得非常权威,但确实起到了一个探索的过程,这些探索像从四面八方出发,慢慢堆积出前端这座大厦的主体框架,并且已经在添砖了。

举一个例子,前端推行函数式编程。而函数式的特点就是纯函数,纯函数是一个无状态的运行器,无论多少次,只要给的输入相同,输出也一定相同。那么这就会有一个疑问,既然相同输入是一样的输出结果,为何不缓存起来呢?是的,最大的问题是,要以怎样的代码来实现,让开发者可以非常爽的使用这个工具,写最少的代码,以最浅薄的认知,就实现这个效果呢?有一个包,叫reselect,它实现了一套这样的机制。而redux中的reducer也要求是纯函数,因此,把这两者结合起来,就得到了一个答案。

当你读到这里,你可能蒙圈儿了。这篇文章到底要讲什么?下面,我们就将正式的进入我们的话题。

驱动模式

而前端领域抽象化话题下,有个话题不得不单独拿出来讲,那就是程序的驱动模式。

什么是程序的驱动模式?简单的说,就是一套程序里面,它依靠何种模式去运行。一旦在技术选型中确认了驱动模式,这个应用的一生就不得不在这个模式下开发,驱动模式就是它的基因。想要更换驱动模式?不可能的,即便是重构,也不可能,除非你的上级允许你把原有产品当作一个新产品,完完全全重新写过,否则永远无法逃脱这个驱动模式。

举个例子,如果你的应用一开始选择了react作为基本库,那么后面切换到vue或者angular可能吗?不可能。但是,如果你后面切换到taro的体系,可能吗?完全没问题。因为react和taro的驱动模式完全一模一样,因为taro就是按react的模式开发的。同样的道理,使用zetop替代jquery是可以的,使用requirejs替代seajs也是可行的,使用angular2替代angular1比较困难,但大体还是有办法。用rollup替代webpack,用yarn替代npm,用其他什么东西替代babel,只要它们的驱动模式相同,就是可行的,只是需要付出迁移成本。

虽然我的资历尚浅,但是很幸运的是,我接触到了非常多的前端框架(框架级库)。下面我列出:

  • jquery
  • backbone
  • angular
  • react
  • vue

这里列出来的5个,代表着过去10年来,前端领域最为重要的东西:如何驱动一个应用。

答案很明显,jquery通过简化DOM操作,同时它提供了非常多的辅助方法,让开发者极其迅速的实现应用交互。可以说,jquery就是前端领域的诺基亚,若不是react的出现,它还会过得很舒服。那么问题来了,为什么backbone和angular没有打败jquery?其实说实话,它们根本没有要打架的意思,它们都拥抱jquery。backbone提供的是数据层面的模式,视图操作还是要靠jquery。angular更不用说,干脆直接集成jquery。这究竟是为什么?

实际上,如果你慢慢读我下面的内容,你就会发现,他们是在同一种驱动模式下实现的东西,只是解决了不同的问题而已。其中非常值得一提的是backbone,它是这一时期的最高提炼,甚至有些过了头。backbone的终极,是要建立一套数据驱动视图的机制,但是它只管数据,而不管视图,它差就差了这一步,如果它能够在“驱动视图”这个层面有所突破,比如它在它那个时候想到“数据改动时,找出最小的改动范围,只更新这部分数据对应的视图”这样的方案的话,那么后面可能就没react多少事了。可惜啊可惜,那个时代,思维可能还不能这么超前,所以今天,backbone就像完成了历史使命一样,等待着失去生命那一天。

是的,“数据驱动视图”,是react和vue大获成功的核心所在。react最终找到了突破backbone没有突破的那个点,那就是用virtual DOM来实现数据到视图这个过程。

说了这么多,这5个框架的最本质区别是什么?答案很明显啊:驱动模式。

  • jquery、angular、backbone:事件驱动
  • vue、react:数据驱动(这里还有更深的讨论)

backbone虽然想要解决“数据驱动视图”这个问题,但是很无奈,它构建了数据响应的一种方式,也就是和jquery、angular一模一样的方式:事件响应。

响应式编程

阅读本文,你需要有一种思维的跳跃过程。终于,你看到了标题中提到的东西。为什么现在才讲到标题上的东西?因为,终于出现了“事件响应”。事件响应,它是响应式编程的一种。

所谓响应式编程,是指不直接进行目标操作,而是用另外一种更为简洁的方式通过代理达到目标操作的目的。举个例子,还是virtual DOM,通过修改数据,实现对DOM的更新。那么问题来了,修改数据到DOM更新这个过程,怎么实现联动呢?再说明白一点,这套代码怎么在我修改了数据之后,去更新DOM呢?如果是react,那就比较好解释,通过setState方法更新状态,并且setState方法内会联动去执行virtual DOM中的diff和patch操作,这样就会更新界面。但是在vue里面就相对复杂一些,vue里面直接修改this上面的一个属性,就可以更新界面了。虽然我们现在都知道,vue是用defineProperty重写了属性的setter,但是这一整套机制实现起来,可不是三两句就说完的。

react之所以好解释,是因为如果单纯讲react本身,它其实在响应式这个问题上和vue有非常大的区别,因为如果单纯看setState,它根本没有响应式,它的响应,是要通过在jsx上绑定事件来实现,因此,单纯看react,它的响应式和angular并无大异,甚至还不如angular。这可能会气坏react的追随者,但事实就是如此。angular的脏检查机制,从体系的层面讲,等同于react里面setState+virtual DOM,而angular里面不需要setState,而是像vue里面一样直接修改数据,编程体验上更舒服的多。那么是什么让react变得不一样?是redux!!!是的,redux及其生态,简直就是这个时代最最最了不起的发明之一,当然,redux是按flux实现的,因此,说Facebook的工程师伟大,也不为过。实体的东西叫了不起,思想的东西才叫伟大。

回到响应式这个话题。

一套代码里面,怎么做到,当一个东西发生了变化,另外一个东西知道它变了,自己也马上作出调整?

我们来看看响应式和非响应式的区别:

// 非响应式
var a = 1
var b = a + 3
var _temp = a

setInterval(() => {
  if (_temp !== a) {
    b = a + 3
    _temp = a
  }
}, 16)

上面这段代码超级容易理解。b是依赖于a的,当a发生变化的时候,b也发生变化。那么非响应式是怎么做的?写一个定时器,不断跑,如果在跑的过程中,发现a变了,那么赶紧把变化之后的值运算之后给b,这样b也就跟着变了。

// 响应式
$scope.a = 1
$scope.b = a + 3

$scope.$watch('a', (a) => {
  $scope.b = a + 3
})

上面这段代码也比较容易理解。用一个$watch方法去观察a这个属性,如果它变了,马上执行watch的第二个参数函数。“观察”,这个词引出了一个设计模式:观察者模式。被观察的对象,将要观察的部分,以及发生变动后要做什么事情,这两个东西交给观察者,当观察者发现被观察对象的这个部分发生变动的时候,就执行要做的事情。这就是观察者模式的基本思路。这种思路普遍存在于jquery、angular、backbone中,这也是早期框架、库无法逃脱的宿命,它们遵循这一驱动模式。

而响应式编程,就是这一驱动模式下的一种编程方式。开发者写一段代码要实现某个操作时,他并不立即用代码去写这个操作,而是使用了一个代理(这个代理一般由框架或库实现),这个代理的作用是,当用户进行了某个操作时,触发了某个变动(事件或数据变动),而这个变动触发了代理中的某些特定项,而这些特定项被触发时,和它们绑定的目标操作就会自动执行。虽然这个过程比直接用代码写操作过程本身复杂,但是对于开发者而言不是,开发者只写用户进行操作时会触发哪个变动,这样代码量就极速下降,甚至只需要一行代码。

这就是响应式编程的优势,它利用代理(一般是经过高级封装的一套逻辑)阻断了变动和操作的直接关系,而是将变动和操作分离,但通过代理,又可以准确的执行变动带来的操作。

响应式的分流

当知道什么是响应式编程之后,我们就该讨论vue和react+redux的不同了。不过我可不是直接的人,在没有理清楚逻辑的时候,直接告诉你答案显得轻浮。

我们接下来要讨论的是,世界上都有哪些已有的响应式编程。原来,响应式编程还要分流派。没错!

事件响应

这是我们最早知道的一种响应式编程方式。时间倒退10年,我们会在网页中,利用DOM节点的事件钩子来做一些事情,例如当用户输入关键字的时候,利用xhr搜索,让用户可以看到一个推荐列表。现在听起来这个功能好土啊,但是回到10年前,真的不得了,我记得百度是2010年才有这个功能的吧。

但现在是2018年了,事件响应简直简单的要死,连HTML5都规定了addEventListener这样的api,简直抢了jquery的饭碗。但是,我还是要提backbone,虽然这件事是jquery先做的,什么事?那就是抽象出事件响应的书写方式,也就是提供on/off/trigger这三个主要方法,实现一整套事件的绑定、解除、触发逻辑。之所以觉得backbone更高级,是因为backbone试图完全脱离view层面,jquery的这些方法,大部分还是向DOM节点绑定事件,但backbone完全是自定义事件,脱离了DOM事件体系,触发事件是为了修改数据。

angular里面对事件响应做了更高级对封装,它把对DOM节点绑定的事件和对数据操作绑定的事件这两件事抹平,成为一件事,它把点击抽象为ng-click,ng-click实际要做两件事,一件是绑定事件到DOM节点上,另一件是当DOM事件被触发时同时触发绑定的数据操作。因此,当ng-click传入的函数被执行时,会同时执行所有$watch的函数,实现脏检查。angular本身实现的是backbone那一套事件响应,但同时,它也借助了DOM事件响应的原生特性。这使得angular成为早起最不得了的框架。

数据响应

借鉴于angular,但和angular不同,vue走了另外一条路。vue要做的,是解决backbone没有解决的问题。它不去寻求中间的那一层代理,而是直接实现数据变动的联动效果。在前面举例一个数据变了另外一个数据跟着变的代码的时候,有一种更快速的实现方式:

var a = 1
var b = a + 3

function setA(value) {
  a = value
  b = a + 3
}

在每次想要修改a的时候,调用setA,而非直接a = 0,这样可以做到a变的时候,b也跟着变。这叫响应式?如果非得说概念的话,这还真是,只是代码看上去不那么优雅吧。

不知道你有没有用过chai.js,里面有一种should方式。这种方式修改了整个作用域,使得要测的变量拥有了should属性,非常了不起。为什么要讲这个?因为我们也可以用一种方式,不要用setA这么俗的方式修改a,因为太不直观了,我就想要a = 0。

vue就是干了这么一件事,它抹掉了setA这个操作,使得直接修改this上的某个属性时,就可以触发目标操作(更新界面)。这种将其他操作抽象到数据操作上的响应模式,就叫“数据响应”。它把对界面操作的目标,抽象为对数据操作,也就是抹平了angular里面的$watch,抹平了backbone里面的on/trigger,其实也就是抹平了事件响应里面的“观察者”这个环节,也就是不需要观察者,因为它不依赖于事件

基于数据响应,其实可以做非常多的事。在vue里面,数据响应的下一步是通过virtual DOM实现界面的更新。而如果将这个模式运用到服务端开发,也是可以的。我之前发布了自己写的最新的包objext,它就是将数据响应抽象化,使得数据响应脱离vue这种要操作界面的具体场景,数据响应,应该可以运用于任何场景。当然,objext只是一个非常小的东西,如果想要更加高级功能的,可以了解下mobx。

事件流响应

2018年真是多事之秋,原本以为数据响应,已经是最了不起的模式了,然而,RxJS的突然爆热,让响应式编程出现了新的视野,原来以为只有事件响应和数据响应,没想到响应式里面还有新的风骚操作。

RxJS并非完全首创,实际上HTML5已经有类似的东西出来了,那就是MutationObserver,这个看上去很容易让人忽略的接口,却对于一不小心看到的开发者来说,简直就像捡到一块宝。MutationObserver将DOM的操作变为可观察的,在这之前,我们操作DOM,没有一个事件可以知道,一个DOM节点是不是被删掉了,是不是被修改了,而有了MutationObserver之后,就可以做到了。既然DOM是一个对象,那么基于同样的逻辑,能否实现一个东西,可以让一个普通的js对象也可以转变为可观察的呢?RxJS孕育而生。了解RxJS的同时,需要了解ReactiveX,也就是说,这是一种编程方式,它在不同的语言中被实践,不单单包括js。

那么到底什么是ReactiveX呢?官方的定义是:

ReactiveX is a combination of the best ideas from
the Observer pattern, the Iterator pattern, and functional programming。

它将事件再度抽象,因为一个应用中,事件往往不是单独存在的,而是一系列事件相继被触发,因此,它提出了streams的概念,也就是“流”,事件流,总结起来,它就是基于“可观察的事件流”的编程方式。当然,它提到了自己是函数式的编程,这可能是为了蹭热度,强制要让开发者体验最新潮的开发方式,但函数式并非它的最终极目标,没有函数式,它照样让开发者体验极致开发,有了函数式,使得它熠熠生辉。

那么,RxJS到底优秀在什么地方呢?RxJS的本质和事件响应一样,是观察者模式的一种实践,通过内部机制,实现观察者,同时开发者可以通过subscribe方法进行订阅,从而在特定的事件中,达到自己的目的。但是,单有观察者模式的实践不足以使它优秀,构建“流”才是它的杀手锏。RxJS是怎么实现“流”的,那就是它结合了迭代器模式。

什么是迭代器模式?就是开发者可以自己创建一个迭代器,在遍历过程中,开发者创建的这个迭代器规定了遍历的内在逻辑。在RxJS开发时,开发者可以自己规定迭代器,把迭代器作为被观察对象,这样,在运行过程中,事件流(本质上是一个事件订阅序列)就会安装迭代器内的逻辑进行流动。

除此之外,RxJS更是抽象出事件与数据之间的映射关系。我们都知道,virtual DOM抽象出了数据和真实DOM的映射关系,数据改变,DOM改变。RxJS则是抽象出事件与数据之间的映射关系,事件发生,数据按照规定发生变化。RxJS通过各种map方法,抹平了事件和数据、事件和事件的分离状态,使得事件在RxJS的体系里面,是有序的,可映射为数据变化的东西。因此,RxJS里面的响应方式是:你不需要关心事件本身,而只需要关心事件所映射的数据变化。

虽然RxJS的编程体验非常好,但是有一个问题在于,它是完全新的驱动模式。它不仅改变了开发者的开发习惯,更重要的是,它对项目具有侵入性。我已经说过,要使得一个已有的项目改变驱动模式,是不可能的,如果要在一个原有项目中重新使用RxJS,几乎不可能。而且它的api超级多,使得新晋的开发者可能望而却步。但现在已经是2018年了,什么样的复杂模式不应该了解一下呢?

数据流响应

很明显,有“流”的概念之后,“数据流”的概念也呼之欲出。数据响应和事件响应的区别是,不需要“观察者”,对数据的操作更加直接。但是有一个问题是,当一套复杂的数据响应被应用于一套复杂的应用中时,开发者往往在响应来响应去的连环嵌套响应中被搞昏头,因为数据的响应而牵一发动全身,导致整个响应很难控制,这是数据响应必须解决的问题。

为了解决这个问题,vue推出了vuex。react本身就没有响应,数据是单向流的,不存在这个问题,但是也正因为react没有响应,所以开发体验极差,因此,有了redux和react-redux。

数据流响应的本质,是一个状态机。它确定了数据在某一时刻的特定状态,数据的不断变化是可以被监控的,上一个状态是什么,变化后现在的状态又是什么,都可以被开发者知道。靠什么来维持这种数据流呢?redux发明了reducer机制,通过纯函数式的状态更改器,来保证每一个状态都是独特的不被污染的。

但是,实际上,redux在“响应”上做的并不完美。react-redux顶多做到了“状态的改动自动映射到界面的改动”,但是它没有解决的是,在数据和状态之间做好映射。现在的redux,你需要创建action和触发dispatch,有没有一种方式,可以不需要手动去触发dispatch,数据的响应是事先安排好的,当数据发生变化时,自动dispatch?这样可以更完美的提升开发体验。虽然mobx是这样的,但是它忘记抽象出数据流,用mobx管理数据,更多的是看中它的响应,但你不能保证对整个应用的状态的准确把握。

由此,在“数据流响应”这个点上,实际上,还没有一套完美的解决方案。另外,有人将RxJS和redux结合起来,既发挥了RxJS在事件管理上的优雅,又保证了数据流的准确,但这一结合也仅仅主要是为了解决redux在异步数据数据处理中的问题,没有真正抽象出数据流动本身的管理。或许,接下来的一两年,冒出来的新东西,就是在解决这个痛点也说不定。

小结

本文从前端的开发体验入手,阐述了“抽象化”“驱动模式”“响应式编程”等问题。前端编程是面向用户体验的编程,它不仅要考虑界面呈现的友好、业务逻辑的准确,还要考虑在编程中如何精准、快速地响应用户操作。响应式编程,是未来的一个趋势,但响应式编程不只有ReactiveX,不应该一提到响应式编程,就限定于ReactiveX。它是一整套抽象逻辑,除了本文提到的四种响应式之外,说不定再两年,又有新的响应式也不定。

2018-10-02 283 , , ,

为价值买单

本文价值2.83RMB