我是日安

在完成 reactive 的基本实现之后，接下来会遇到几种常见且必须处理的情况： 原始对象传入 Reactive 对象 Reactive 对象再次传入 Reactive 对 Reactive 对象重复

上一次我们提到： 每个对象的每个属性都需要自己的 Dep。 如何建立 target.a → Dep 的对应关系？ 如何在不污染原始对象的情况下存储这个关系？ 我们可以先来做一个简单的比较。 Ref 与

在之前的文章中，我们已经完成了 ref 的实现，它能将原始值包装成响应式对象。现在，我们要接着完成响应式系统核心的另一部分：reactive 函数。我们的目标是接收一个完整的对象，并返回一个代理对象，

在打造响应式系统时，一个容易遇到的状况是，effect 在执行期间同时“读取”又“写入”同一个依赖，这会造成自我触发 (self-trigger)。 effect 为了读值而被追踪为依赖，但它在同一次

昨天，我们完成了“依赖清理”机制，让 effect 能够正确处理动态变化的依赖关系。然而，这也带来了一个新的性能问题：当依赖频繁变化时，系统需要不断地创建和销毁 Link 节点。每次建立依赖关系都会触

在实际情况中，effect 函数内部的依赖，常常因为条件分支（比如 if...else）而发生变化，这种情况称为「动态依赖」。 动态依赖会带来一个问题：在某次执行中不再被使用的旧依赖，如果没有被处理好

在解决了链表节点指数增长的问题后，我们还需要关注依赖的有效性。 effect 的执行路径可能因为条件判断或程序逻辑不同而改变，导致某些依赖在本次执行中已经不再需要。 如果这些“过期依赖”没有被清理：

昨天我们了解到，当 effect 函数依赖多个响应式变量时，会再次触发指数级更新。 我们来回顾一下之前的做法： run() 函数首先会将 depsTail 设为 undefined。 后续的依赖收集中

昨天我们解决了单一依赖所导致的指数增长问题。然而，在真实的开发场景中，一个 effect 函数往往需要依赖多个响应式变量。现在我们试着新增多个依赖，在示例中加入第二个响应式变量 count，并让 ef