唐霜的博客

最近这两天一直在想一种实现方式。我们现在的前端应用，实现上基于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那一套。

有一个项目，为了方便使用了Parcel打包，结果来事，构建结果中来这么一出：

老哥，这个变量根本就没有被赋值过啊，当然是undefined！坑的一笔！

在表单开发中，我们往往会因为label字数不同而无法保证不换行的情况下还要对齐。怎么解决呢？当然是上脚本来处理。

function adjustNodesWidthToBeSame(selector) {
  const getTextWidth = (text, font) => {
    const canvas = document.createElement('canvas');
    const context = canvas.getContext('2d');
    context.font = font;
    const dism = context.measureText(text);
    return dism.width;
  };
  const labels = document.querySelectorAll(selector);
  const items = Array.from(labels);
  let maxWidth = 0;
  items.forEach((item) => {
    const text = item.innerText;
    const { font } = window.getComputedStyle(item);
    const width = getTextWidth(text, font);
    maxWidth = Math.max(maxWidth, width);
  });
  items.forEach((item) => {
    /* eslint-disable no-param-reassign */
    item.style.width = `${maxWidth}px`;
  });
}

将这个函数在整个界面上的label发生变化的时候执行，它就会自动调整label的宽度来适配最长的那一个。

从大约两年前开始写 nautil，从一开始主要目标是创造一个跨平台开发的框架，现在来看，这个目标开始有所转变了。以前觉得跨平台开发是趋势，是一项重要工作，是亮点，但随着时间的推移，我越来越觉得，跨平台是一种技巧，而不是一种技术。在我长期以来的开发中，我逐渐意识到，项目工程的可靠性是团队/个人开发的重中之重。如何让一个项目的代码组织更加合理呢？特别是以 react 为基础的应用中，怎么去更好的组织码流（代码顺序和引用）？

代码写的多了以后，追求一种抽象的范式。所谓范式，是在方法范畴层面更广的风格。我发现在前端领域，react 和 angular 是两个极端，react 是只关注视图更新，不断深入，寻找各种方式提升视图更新性能，但是在工程性上完全放飞，性能代码量全部由开发者自己去处理。而 angular 反过来，它根本不关注（或者说不是卖点）视图更新问题，angular 沿用了 angularjs 时代的脏检查思路，只是做了优化，做到了没有 digest，只需要一次检查；而在工程性方面，angular 想尽一切办法约束开发者，因此，angular 的语法多得多，所以学习曲线比较漫长，但是我个人认为收益会很大，其中，引入 typescript 以静态类型语言的风格编写应用程序，会让应用更加健壮（但编程的灵活性降低，同时增加了类型编程的麻烦/乐趣），引入 rxjs 让事件处理从原始的 single push 模式升级为 multiple push 模式，增加了事件处理的灵活性；angular 具有 module 和 service 的概念，module 可以认为是一个业务模块（和 react 中的 component 概念相似但不同），包含该模块的所有信息，并通过工具进行解析构建；service 为模块提供处理能力，可以通过 angular 特殊的依赖注入完成比较魔法的写法。

而在 react 的生态中，除了 nextjs 比较知名外，还没有比较成熟的工程框架方案。而且 nextjs 走 ssr 路线，更像是以前的 php 换 nodejs 来过一遍，而非纯前端（运行时）的方案。于是，我想写一个框架来融合各种优秀理念（大部分其实还是我自己的），提供一种可靠的工程性框架的可能性。市面上其实也有一些自称为 react 框架的方案，比如 dva，但是实际上大部分 react+redux+react-router 的项目，就可以称自己为框架，但是，这类框架仍然停留在视图层编程的层面，没有上升为工程性框架，没有提供真正的编程范式。而写 nautil 之初是为了实现跨端开发，但是，随着慢慢深入开发，我发现 nautil 有可能成为真正的对标 angular 的 react 工程性框架。

首先，前端应用需要区分数据、界面和事件，而类似 dva 之类的框架，你按照它的写法，永远只会写出把业务逻辑最终杂糅在视图组件中。没有区分数据和界面，是前端项目目前最大的问题。举一个简单的例子，在一段明显只描述业务逻辑的代码块中，你很容易找到一两句用来处理界面的代码，比如打开一个弹窗、颜色变化等。而 nautil 则首先要求开发者有分层的概念在里面，从代码层面看，就是有关业务的代码写在一个或多个文件中，有关界面的代码写在一个或多个文件中，这两者绝对不会出现直接的联系，这也就是 MVC 中的 M 和 V，同时，需要有一个东西将它们串联起来，也就是 C。在 nautil 中编程，很像传统的 MVC 编程，需要写 .model.js, .controller.js，看上去又回到了 MVC 的老路，但是有一点，这里我们避免了一些坑，我们不可能直接照搬后端的 MVC 概念，后端的 C 才是请求的入口，而在前端 V 才是入口。所以在前端 module 中必须存在视图组建，但可以不存在 controller 和 model。

其次，关于事件，我认为是大部分前端容易忽略的一个点，很多人认为事件就是事件，很简单，没必要整那么复杂。但是在实际开发中，事件几乎串联了所有业务和交互，可以说，没有事件处理就没有这个应用。但是大部分编程，都只有事件回调函数，在 react 中通过 on 开头的一些回调来获得 DOM 的事件回调。但是，回调函数的方式比较钝，当一个动作可能引发一连串非线性的反应的时候，回调函数是不可能解决的。举个例子，比如我们有一个场景，当用户点击 A 时弹出一个弹框，当点击 B 时需要先放大 B 元素然后再相当于点击 A。这里点击 B 就是一个会带来一连串非线性的反应的场景，在 jquery 时代，我们可以通过 trigger A 的 click 来达到这个目的，但是在 react 中，我们无法做到这个效果。而在 nautil 中，我引入了 rxjs 来解决事件处理。普通的回调函数是 single push 模式，只能处理单一线性的任务，而 rxjs 是 multiple push 模式，可以处理多向离散任务，同时，由于 rxjs 的 Subject 既是观察者也是被观察者，所以多个事件之间可以轻松串联起来。在 v0.30 之前，我在 Component 中使用 on/off/emit 作为事件的处理工具，但是这种命名仍然是传统的事件注册与回调的意味，因此，我改为了 subscribe/unsubscribe/dispatch，虽然只是名字的改变，但体现了事件流处理的理念的转变。

最后，Controller 的发明也是非常有意思。一个 controller 观察模型，保管一些用于完成事件到数据交互的组件，这些组件只完成交互（事件->数据），而不完成布局和样式，所以细小碎片化，但是却形成了另外一种模式：业务不仅包含数据描述，还包含交互描述。通过 Model+Controller，我们可以很好的还原需求文档中有关业务逻辑的描述（一般需求文档除了描述业务数据本身，还会描述用户的某一个交互所带来的数据变化，而在这个描述中，往往还没有给出具体的界面效果）。所以，在我看来，一个 Controller 其实是一个交互模型，这个交互模型的基础，就是拥有基于 rxjs 的事件流管理机制。基于这种思想，一个 module 除了视图组件和样式文件之外，其他的都是模型（包括 Service 在内，因为它为业务服务）。只有视图组件是为界面服务的，这就导致我们的开发方式与以往的 react 开发方式具有极大的不同，这个不同非常非常大！可以说，视图组件的编写，只占到整个应用的一小部分，而真正的大头应该是在 Model+Controller 上，这也符合我们对“业务系统的重点是这实现业务”的朴素认知。

2021 年已经 5 月了，今年我做 Robust 的期数特别少，因为手上的工作比较多，同时，我也逐渐发现，要完成一些具有挑战的项目逻辑是比较困难的，不是有了想法和行动，就能做到尽善尽美，特殊的场景实在太多了，想要做一个完完全全通用化的功能模块，几乎是不可能的，这也意味着，未来还有很长的路要走，而且是不可替代的。