关于前端:从Lisp到VueReact再到-Qwit响应式编程的发展历程

微信搜寻【大迁世界】, 我会第一工夫和你分享前端行业趋势，学习路径等等。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。

这篇文章并不是对于响应式的权威历史，而是对于我集体在这方面的经验和观点。

我的旅程始于 Macromedia Flex，起初被 Adobe 收买。Flex 是基于 Flash 上的 ActionScript 的一个框架。ActionScript 与 JavaScript 十分类似，但它具备注解性能，容许编译器为订阅包装字段。我不记得确切的语法了，也在网上找不到太多信息，但它看起来是这样的：

class MyComponent {[Bindable] public var name: String;
}

[Bindable] 注解会创立一个 getter/setter，当属性发生变化时，它会触发事件。而后你能够监听属性的变动。Flex 附带了用于渲染 UI 的 .mxml 文件模板。如果属性发生变化，.mxml 中的任何数据绑定都是细粒度的响应式，因为它通过监听属性的变动。

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
  <mx:MyComponent>
    <mx:Label text="{name}"/></mx:Label>
  </mx:MyComponent>
</mx:Applicatio>

我狐疑 Flex 并不是响应式最早呈现的中央，但它是我第一次接触到响应式。

在 Flex 中，响应式有点麻烦，因为它容易创立更新风暴。更新风暴是指当单个属性变动触发许多其余属性（或模板）变动，从而触发更多属性变动，依此类推。有时，这会陷入有限循环。Flex 没有辨别更新属性和更新 UI，导致大量的 UI 抖动（渲染两头值）。

预先看来，我能够看到哪些架构决策导致了这种次优后果，但过后我并不分明，我对响应式零碎有点不信赖。

AngularJS 的最后指标是扩大 HTML 词汇，以便设计师（非开发人员）能够构建简略的 Web 应用程序。这就是为什么 AngularJS 最终采纳了 HTML 标记的起因。因为 AngularJS 扩大了 HTML，它须要绑定到任何 JavaScript 对象。那时候既没有 Proxy、getter/setters，也没有 Object.observe() 这些选项可供选择。所以惟一可用的解决方案就是应用脏查看。

脏查看通过在浏览器执行任何异步工作时读取模板中绑定的所有属性来工作。

<!doctype html>
<html ng-app>
  <head>
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.8.2/angular.min.js"></script>
  </head>
  <body>
    <div>
      <label>Name:</label>
      <input type="text" ng-model="yourName" placeholder="Enter a name here">
      <hr>
      <h1>Hello {{yourName}}!</h1>
    </div>
  </body>
</html>

这种办法的益处是，任何 JavaScript 对象都能够在模板中用作数据绑定源，更新也能失常工作。

毛病是每次更新都要执行大量的 JavaScript。而且，因为 AngularJS 不晓得何时可能发生变化，所以它运行脏查看的频率远远超过实践上所需。

因为 AngularJS 能够与任何对象一起工作，而且它自身是 HTML 语法的扩大，所以 AngularJS 从未将任何状态治理模式固化。

React 在 AngularJS（Angular 之前）之后推出，并进行了几项改良。

首先，React 引入了 setState()。这使得 React 晓得何时应该对 vDOM 进行脏查看。这样做的益处是，与每个异步工作都运行脏查看的 AngularJS 不同，React 只有在开发人员通知它要运行时才会执行。因而，只管 React vDOM 的脏查看比 AngularJS 更消耗计算资源，但它会更少地运行。

function Counter() {const [count, setCount] = useState();
  return <button onClick={() => setCount(count+1)}>{count}</button>
}

其次，React 引入了从父组件到子组件的严格数据流。这是朝着框架认可的状态治理迈出的第一步，而 AngularJS 则没有这样做。

React 和 AngularJS 都是粗粒度响应式的。这意味着数据的变动会触发大量的 JavaScript 执行。框架最终会将所有的更改合并到 UI 中。这意味着疾速变动的属性，如动画，可能会导致性能问题。

解决上述问题的办法是细粒度响应性，状态扭转只更新与状态绑定的 UI 局部。

难点在于如何以良好的开发体验（DX）来监听属性变动。

Backbone 早于 AngularJS，它具备细粒度的响应性，但语法十分简短。

var MyModel = Backbone.Model.extend({initialize: function() {
    // Listen to changes on itself.
    this.on('change:name', this.onAsdChange);
  },
  onNameChange: function(model, value) {console.log('Model: Name was changed to:', value);
  }
});
var myModel = new MyModel();
myModel.set('name', 'something');

我认为简短的语法是像 AngularJS 和起初的 React 这样的框架取而代之的起因之一，因为开发者能够简略地应用点符号来拜访和设置状态，而不是一组简单的函数回调。在这些较新的框架中开发应用程序更容易，也更快。

Knockout 和 AngularJS 呈现在同一期间。我从未应用过它，但我的了解是它也受到了更新风暴问题的困扰。尽管它在 Backbone.js 的根底上有所改进，但与可察看属性一起应用依然很蠢笨，这也是我认为开发者更喜爱像 AngularJS 和 React 这样的点符号框架的起因。

然而 Knockout 有一个乏味的翻新 —— 计算属性，它可能曾经存在过，但这是我第一次据说。它们会主动在输出上创立订阅。

var ViewModel = function(first, last) {this.firstName = ko.observable(first);
  this.lastName = ko.observable(last);
  this.fullName = ko.pureComputed(function() {
    // Knockout tracks dependencies automatically.
    // It knows that fullName depends on firstName and lastName,
    // because these get called when evaluating fullName.
    return this.firstName() + " " + this.lastName();
  }, this);
};

请留神，当 ko.pureComputed() 调用 this.firstName() 时，值的调用会隐式地创立一个订阅。这是通过 ko.pureComputed() 设置一个全局变量来实现的，这个全局变量容许 this.firstName() 与 ko.pureComputed() 通信，并将订阅信息传递给它，而无需开发者进行任何额定的工作。

Svelte 应用编译器实现了响应式。这里的劣势在于，有了编译器，语法能够是任何你想要的。你不受 JavaScript 的限度。对于组件，Svelte 具备十分天然的响应式语法。然而，Svelte 并不会编译所有文件，只会编译以 .svelte 结尾的文件。如果你心愿在未通过编译的文件中取得响应性，则 Svelte 提供了一个存储 API，它短少已编译响应性所具备的魔力，并须要更明确地注册应用 subscribe 和unsubscribe。

const count = writable(0);
const unsubscribe = count.subscribe(value => {countValue = value;});

我认为领有两种不同的办法来实现同样的事件并不现实，因为你必须在脑海中放弃两种不同的思维模式并在它们之间做出抉择。一种对立的办法会更受欢迎。

RxJS 是一个不依赖于任何底层渲染零碎的响应式库。这仿佛是一个劣势，但它也有一个毛病。导航到新页面须要拆除现有的 UI 并构建新的 UI。对于 RxJS，这意味着须要进行很多勾销订阅和订阅操作。这些额定的工作意味着在这种状况下，粗粒度响应式零碎会更快，因为拆除只是抛弃 UI（垃圾回收），而构建不须要注册 / 调配监听器。咱们须要的是一种批量勾销订阅 / 订阅的办法。

const observable1 = interval(400);
const observable2 = interval(300);
const subscription = observable1.subscribe(x => console.log('[first](https://rxjs.dev/api/index/function/first):' + x));
const childSubscription = observable2.subscribe(x => console.log('second:' + x));
subscription.add(childSubscription);
setTimeout(() => {
  // Unsubscribes BOTH subscription and childSubscription
  subscription.unsubscribe();}, 1000);

大概在同一时间，Vue 和 MobX 都开始尝试基于代理的响应式。代理的劣势在于，你能够应用开发者喜爱的洁净的点表示法语法，同时能够像 Knockout 一样应用雷同的技巧来创立主动订阅 —— 这是一个微小的胜利！

<template>
  <button @click="count = count + 1">{{count}}</button>
</template>

<script setup>
import {ref} from "vue";

const count = ref(1);
</script>

在下面的示例中，模板在渲染期间通过读取 count 值主动创立了一个对 count 的订阅。开发者无需进行任何额定的工作。

SolidJS 的毛病是无奈将援用传递给 getter/setter。你要么传递整个代理，要么传递属性的值，然而你无奈从存储中剥离一个 getter 并传递它。以此为例来阐明这个问题。

function App() {const state = createStateProxy({count: 1});
  return (
    <>
      <button onClick={() => state.count++}>+1</button>\
      <Wrapper value={state.count}/>
    </>
  );
}

function Wrapper(props) {return <Display value={state.value}/>
}
function Display(props) {return <span>Count: {props.value}</span>
}

当咱们读取 state.count 时，失去的数字是原始的，不再是可察看的。这意味着 Middle 和 Child 都须要在 state.count 扭转时从新渲染。咱们失去了细粒度的响应性。现实状况下，只有 Count: 应该被更新。咱们须要的是一种传递值援用而不是值自身的办法。

signals 容许你不仅援用值，还能够援用该值的 getter/setter。因而，你能够应用信号解决上述问题：

function App() {const [count, setCount] = createSignal(1);
  return (
    <>
      <button onClick={() => setCount(count() + 1)}>+1</button>
      <Wrapper value={count}/>
    </>
  );
}
function Wrapper(props: {value: Accessor<number>}) {return <Display value={props.value}/>
}
function Display(props: {value: Accessor<number>}) {return <span>Count: {props.value}</span>
}

这种解决方案的益处在于，咱们不是传递值，而是传递一个 Accessor（一个 getter）。这意味着当 count 的值产生更改时，咱们不用通过 Wrapper 和 Display，能够间接达到 DOM 进行更新。它的工作形式十分相似于 Knockout，但在语法上相似于 Vue/MobX。

假如咱们想要绑定到一个常量作为组件的用户，则会呈现 DX 问题。

<Display value={10}/>

这样做不会起作用，因为 Display 被定义为 Accessor：

function Display(props: {value: Accessor<number>});

这是令人遗憾的，因为组件的作者当初定义了使用者是否能够发送 getter 或 value。无论作者抉择什么，总会有未涵盖的用例。这两者都是正当的事件。

<Display value={10}/>
<Display value={createSignal(10)}/>

以上是应用 Display 的两种无效形式，但它们都不能同时成立！咱们须要一种办法来将类型申明为根本类型，但能够同时与根本类型和 Accessor 一起应用。这时编译器就出场了。

function App() {const [count, setCount] = createSignal(1);
  return (
    <>
      <button onClick={() => setCount(count() + 1)}>+1</button>
      <Wrapper value={count()}/>
    </>
  );
}
function Wrapper(props: {value: number}) {return <Display value={props.value}/>
}
function Display(props: {value: number}) {return <span>Count: {props.value}</span>
}

请留神，当初咱们申明的是 number，而不是 Accessor。这意味着这段代码将失常工作

<Display value={10}/>
<Display value={createSignal(10)()}/> // Notice the extra ()

但这是否意味着咱们当初曾经毁坏了响应性？答案是必定的，除非咱们能够让编译器执行一个技巧来复原咱们的响应性。问题就出在这行代码上：

<Wrapper value={count()}/>

count()的调用会将拜访器转换为原始值并创立一个订阅。因而编译器会执行这个技巧。

Wrapper({get value() {return count(); }
})

通过在将 count() 作为属性传递给子组件时，在 getter 中包装它，编译器胜利地提早了对 count() 的执行，直到 DOM 理论须要它。这使得 DOM 能够创立根底信号的订阅，即便对开发人员来说仿佛是传递了一个值。

益处有：

清晰的语法
主动订阅和勾销订阅
组件接口不用抉择原始类型或 Accessor。
响应性即便开发人员将 Accessor 转换为原始类型也能失常工作。

咱们还能在此基础上做出什么改良吗？

让咱们设想一个产品页面，有一个购买按钮和一个购物车。

在下面的示例中，咱们有一个树形构造中的组件汇合。用户可能采取的一种可能的操作是点击购买按钮，这须要更新购物车。对于须要执行的代码，有两种不同的后果。

在粗粒度响应式零碎中，它是这样的：

咱们必须找到 Buy 和 Cart 组件之间的独特根，因为状态很可能附加在那里。而后，在更改状态时，与该状态相关联的树必须从新渲染。应用 memoization 技术，能够将树剪枝成仅蕴含上述两个最小门路。尤其是随着应用程序变得越来越简单，须要执行大量代码。

在细粒度反应式零碎中，它看起来像这样：

请留神，只有指标 Cart 须要执行。无需查看状态是在哪里申明的或独特先人是什么。也不用放心数据记忆化以修剪树。精密的反应式零碎的益处在于，开发人员无需任何致力，运行时只执行最大量的代码！

精密的反应式零碎的手术精度使它们非常适合懈怠执行代码，因为零碎只须要执行状态的侦听器（在咱们的例子中是 Cart）。

然而，精密的反应式零碎有一个意外的角落案例。为了建设反馈图，零碎必须至多执行所有组件以理解它们之间的关系！一旦建设起来，零碎就能够进行手术。这是初始执行的样子：

你看出问题了吗？咱们想懈怠地下载和执行，但反馈图的初始化强制执行应用程序的残缺下载。

这就是 Qwik 发挥作用的中央。Qwik 是精密的反应式，相似于 SolidJS，意味着状态的变动间接更新 DOM。（在某些角落状况下，Qwik 可能须要执行整个组件。）然而 Qwik 有一个诡计。记得精密的反馈性要求所有组件至多执行一次以创立反馈图吗？好吧，Qwik 利用了组件在 SSR/SSG 期间曾经在服务器上执行的事实。Qwik 能够将这个图形序列化为 HTML。这使得客户端齐全能够跳过最后的“执行世界以理解反馈图”的步骤。咱们称这种能力为可恢复性。因为组件在客户端上不会执行或下载，因而 Qwik 的益处是应用程序的即时启动。一旦应用程序正在运行，反馈就像 SolidJS 一样准确。

本文介绍了响应式编程的历史和倒退，响应式编程是一种编程范式，它强调了数据流和变动的传递。文章从晚期的编程语言开始讲述，比方 Lisp 和 Smalltalk，它们的数据结构和函数式编程的个性促成了响应式编程的倒退。而后，文章提到了响应式编程框架的呈现，如 React 和 Vue.js 等。这些框架应用虚构 DOM（Virtual DOM）技术来跟踪数据变动，并更新界面。文章还探讨了响应式编程的长处和毛病，如可读性和性能等。最初，文章预测了将来响应式编程的倒退方向。

总的来说，本文很好地介绍了响应式编程的历史和倒退，深入浅出地讲述了它的长处和毛病。文章提到了很多理论利用和框架的例子，让读者更好地了解响应式编程的概念和实际。文章还预测了将来响应式编程的倒退方向，这对读者和开发者有很大的启发作用。

代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。

原文：https://www.builder.io/blog/history-of-reactivity

有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。

本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。

关于前端:从Lisp到VueReact再到-Qwit响应式编程的发展历程

Flex

AngularJS

React

粗粒度响应性

细粒度响应性

Backbone.js

Knockout

Svelte

RxJS

Vue 和 MobX

SolidJS

signals

响应性和渲染

Qwik

总结

交换