唐霜的博客

多态的简单解释是，调用相同的接口传入相同的参数，由于被调用的设备不同产生了不同的副作用/效果。例如同样是console.error，在chrome浏览器里面和在nodejs的command inline interface里面，效果就不同。基于这一特性，我们可以对接口进行抽象，简单的例子如下：

interface Person {
  sing(song: object): string;
}

function sing(person: Person, song: object): string {
  return person.sing(song)
}

上面的代码里面，我们创建了一个sing函数，它接收person这个对象，并调用它的sing方法。由于类型的约束，接收的person一定会有sing方法。但是，这个person.sing这个方法会做什么事呢？对于sing这个函数它并不知道，它只是调用了person的sing方法而已。所以，我们基于多态实现person。

class Person1 implement Person {
  sing(song: object) {
    const { lyric } = song
    console.log(lyric) // 打印到屏幕上
    return lyric
  }
}

class Person2 implement Person {
  sing(song: object) {
    const { lyric } = song
    Audio.paly(lyric) // 播放声音
    return lyric
  }
}

两个类实现了相同的Person接口，但是在实现的时候，又使用了不同的副作用，这就是多态。

那么，多态有什么用呢？对前端有什么影响呢？

第一点，是代码写法上的变化。

以前我们喜欢extends来得到一个具体的类，比如 class Person 有一个 sing 方法，我们通过 extends 来覆盖这个方法。这也就意味着，你的代码里面，一定会引入原来的 Person，并且原来的 Person 里面的 sing 方法一定会在最终打包的代码里面，虽然它永远都用不到。而新的写法是在调用函数的时候，把类的实例传入进去，这把引入模块的工作交给函数外部去做，这就让到处这个函数的模块的代码瞬间减少了。

第二点，是架构设计上的变化。

以前我在架设react项目时，会以View作为入口，应用的一切都是先有View，在View中去引入需要用到的Model等其他模块，这也就意味着，应用以View为顶层入口，所有的代码层层引入，绑定在了一起。现在，我们利用多态，换一个角度。我们让开发者自己写入口，这个入口我们称为Controller，我们提供的框架不是让View去使用Model，而是反过来，让Controller去使用View，让Model去使用View。这个场景下面，View必须按照接口约束提供接口给Model使用，这个时候，我们写Model就可以反过来考虑控制View（这里的Model是指ViewModel）。这种转变非常神奇，从框架层面，它颠覆了传统前端的开发方式。

最近这两天一直在想一种实现方式。我们现在的前端应用，实现上基于DOM是最好的最流行的，不过，大部分前端都构建了自己的路有系统，这又依赖BOM。也就是说，目前大部分前端应用，都是基于DOM/BOM实现的。那么，我是否可以创建一个通用的DOM/BOM平台，让这些应用跑在这个平台上。

让前端应用跑在一个DOM/BOM平台上，听上去有点莫名其妙，为啥不跑在浏览器里面？没错，我就是想脱离浏览器跑这些应用。比如在nodejs里面跑（目前有JSDOM可以支持这个效果），虽然没有界面可以看，但是可以用来做一些单元测试的工作。比如在webworker中跑，众所周知，webworker是没有DOM API的，假如有了这个平台，那么就可以在worker中跑一个vue应用（虽然没有界面）。同样的道理，能否更远一点，跑在非js的环境中，比如flutter（目前阿里开源的Kraken支持这个效果）甚至C++写的原生应用中。想一想，在一个树莓派中跑一个vue应用。于是，我想出了这样一个架构：

其中，VBOM这一层和Driver framework这一层是实现的核心。VBOM是用纯js实现的DOM+BOM环境，只要把已有的vue代码，包在一个VBOM实例的闭包里面（用babel把全局变量的引用切换到window上），那么vue代码所做的任何关于DOM/BOM的操作，都是在这个VBOM的实例内部完成。Driver framework则是监听/操作这个VBOM实例，对接不同的平台，比如小程序，由于小程序是js写的，所以，引用js-driver，然后在driver的各个生命周期钩子函数上写小程序要做的事情，driver会把VBOM中有关DOM/BOM的变化告诉给小程序，也会把来自小程序的消息发送给VBOM产生新的副作用。而flutter上，我们可以使用dart-driver，原生应用可以使用cpp-driver，python-driver, rust-driver等等，通过driver之后，终端代码里面只写终端语言代码，不需要写任何js相关的东西。而回过来，应用这端，开发者只需要写vue或react，不需要考虑自己的应用会在哪个环境里面去跑。

再用一个基于webworker的微前端方案的例子说明：

微前端要解决的是一个沙箱问题，比如一个vue应用，要在宿主应用中加载运行，那么，这个vue应用里面可能操作DOM, location, history等等，这些东西会导致vue这个子应用和宿主应用去抢location, history进行操作。我在mfy中的做法是创建一个iframe，然后把里面的window, location, history借过来给子应用去操作，通过监听，同步子应用和父应用的相关信息，这样就不会出现抢的局面。但是，由于浏览器环境中的特殊原因，目前所有的微前端方案，实现沙箱都需要借助Function来实现，同时还需要用with这个性能极差的语法（而且这个语法已经被抛弃了）来解决全局变量修改问题（虽然也可以用babel进行编译处理来去掉with语法）。这些方案都无法避免父子应用的某些冲突，特别是子应用代码运行过程中发现当前提供的资源不符合自己代码实现的逻辑，报错。

既然浏览器环境下沙箱问题这么多，性能这么差，那么我能不能把沙箱迁移到一个webworker中，在worker环境下，根本不存在抢资源问题，也不需要用Function来包裹vue代码。但是，worker中没有DOM啊，也没有location, history，所以就想到了，我们需要自己造一套DOM/BOM的环境，然后把这套环境放在webworker中，这样可以让vue应用在worker中跑起来，vue操作的，是VBOM，虽然不会报错，但是没有任何界面效果。

所以，接下来，就需要driver出场，driver监听VBOM中的变化，把这些变化交给controller（controller是微前端框架基于js-driver实现的一个运行在webworker中的控制器），controller通过postMessage发送给主线程，由主线程的renderer收到message之后决定怎么修改DOM。当用户点击子应用区域内的某个按钮之后，renderer将该点击事件postMessage给controller，由controller分析并把对应的DOM事件发送给driver，driver知道这个事件发生在哪个DOM节点上，于是在VBOM中对应的节点上触发该事件，VBOM实际上是vue的运行环境，vue组件上的事件被触发，回调函数被执行，引发新的DOM更新，再次走一遍前面的过程。

看上去好绕啊！！！但是，你要知道，其中，对于框架开发者而言，他们维护的是微前端框架，对于宿主开发者而言，他们维护的是微前端框架的配置，对于子应用开发者而言，他们维护的是vue这个应用。真正需要经常调整、修改的，是vue应用这一层，其他两者基本上是以逸待劳，一劳永逸。所以，一旦这一套跑起来之后，不管是vue也好，react也好，开发者只需要了解自己熟悉的基于DOM/BOM的web开发即可，不需要关心自己是在什么环境下运行。这对小程序的开发者而言，肯定深有感触，小程序开发因为有线程约束，导致开发者有的时候非常痛苦，翻边开发文档都找不到问题的根源。而如果有了上面这一套方案，开发者只需要考虑在自己熟悉的web平台上开发即可，而不需要考虑其他。

补充一点，如果需要调用原生的能力，需要框架开发者在driver那一层，向VBOM提供某些接口的能力，比如提供调用摄像头的能力，比如提供app是否被切换到后台运行的事件等等（很多hybird的操作手法）。对于应用的开发者而言，无非是增加了一些特殊接口和事件，仍然还是DOM/BOM那一套。