2020
1 2 3 4 5 6 7 8 9 10 11 12
302020.11

用Proxy拦截class，这种骚操作闻所未闻！

一个突发奇想，如果要拦截class的属性变化，除了用defineProperty进行重写，难道不能用Proxy吗？于是，产生了下面这段代码。

class A {
  name = 'aaa'
  age = 0
  constructor() {
    return new Proxy(this, {
      get: (_, key) => this[key],
      set: (_, key, value) => {
        console.log(key, value)
        this[key] = value
        return true
      },
    })
  }
  say() {
    console.log(this.name, this.age)
  }
  update(key, value) {
    this[key] = value
  }
}

在构造函数中return new Proxy(this)真是够风骚的操作。

09:47:22 已有1条回复
  1. 一般吾辈会用 class static function 或者注解来解决
    #985 rxliuli 2020-12-01 12:04 回复
评论
232020.11

等等，这样讨论vue ref-sugar是不讲武德的！

我们讨论ref-sugar本质上在讨论三件事：设计原则，开发体验，实现魔法。

我们现在在该问题上争论，很多人直接从第三点出发，认为实现魔法不好，但实际上，根源在于第一点，vue3发布的ref没有遵循vue原有的设计原则，使得变量的使用在script和template中呈现了两种形态。

export default {
  setup() {
    const count = ref(0)
    const plus = (inc) => count.value += inc // 脚本中使用 count.value
    return { count, plus }
  }
}

<div>{{ count }}</div> // 模板中使用 count

设计原则

Vue的设计原则包含两个基本点：1.通过直接修改状态变量而非调用接口完成响应式，2.接近原始js变量操作而非复杂操作的0成本理解。简单说就是，vue帮你封装好响应式，你只要无脑使用，做到真正0心智模型。但在ref这个点上，0心智失效了，因为我们在脚本中经常忘记.value。

对问题的解决，不能超出设计原则，这是vue所坚守的，超出原则的设计，比如这篇文章，虽然可以解决问题，但是一旦泛滥，那么vue就没啥价值了。

既然在书写时，你经常忘记写.value，那我接下来就让你忘记变得合法合理，所以新的ref提案的目标，就是隐藏.value，让你继续0心智。那就涉及到一个开发体验的问题了，究竟怎么让开发者写代码，才爽呢？

开发体验

在开发体验道路上分出了两条岔路，AoT和Runtime。前者把活交给编译过程，能力实现全靠工具，但是可以随意发明语法，想怎么玩都可以，爽，缺点就是脱离了那套编译工具跑不了，典型就是svelte。后者需要自己写一套基于原始js能力的系统实现效果，提供接口，按照接口文档用就完事了，浏览器里面随便跑，缺点是运行时代码加大，心智负担加剧（要记住用法）。

vue想尽一切办法在两者之间做平衡，几年来，长期坚持能够纯runtime实现，还是干不过js语言本身的限制。所以，新提案ref-sugar妥协了，是纯粹的AoT实现方案。当然，AoT也可以在浏览器端搞编译，就像当年less搞的一样，但很明显，这是歧途，自己在浏览器里面解释执行js是不明智的，太不安全了。

对该方案的喷点，多多少少是由于这个原因。因为如果把解决问题的方法丢给编译器去解决，那还有啥是编译器不能解决的？

所以，能够平息这次风波的根本解决办法，一定是：0心智负担+runtime的方案。连尤大都掉坑的问题，是不是无解了呢？接下来看看实现魔法。

实现魔法

我想，尤大掉坑的根源，可能是对设计原则的误解，认为vue必须是基于单一方案实现响应式，所谓单一方案，就是vue里面只能有数据拦截这一套方案。但是，响应式方案真不止数据拦截这一条路。vue1,2采用了defineProperty方案实现响应式，而vue3采用了Proxy，开发者的心智没有任何负担，反而叫好，这说明，问题的根源不在于实现响应式的内部细节，而在最终表现出来的效果。

所以，为什么vue只能基于单一方案实现响应式？为什么不能同时用两套响应式方案？在ref这个点上，脏检查机制就是一个赠送的方案。（这想法不是我提的）

let a = ref(0, () => a) 
function handle() { 
    a = a + 1 
}
<div @click="handle">{{ a }}</div>
 上面代码里面的关键点在于ref的第二个参数，这个参数返回a，这样，每次在进行重新计算（如被依赖的情况下）时，都读取a这个变量，将采用a最新的值，包括watch，也会使用这第二个函数作为被watch对象是否变化的依据。

另外，js里面有一些魔法可以用上了，主要是valueOf和Symbol.toPrimitive，这两个属性可以帮助我们完成对象的值运算。我简单举个例子你就能明白其中的道理。

var a = {
  value: 1,
  valueOf() { return this.value },
}

var b = {
  value: 2,
  valueOf() { return this.value },
}

接下来我们做这个运行：a + b得到的结果是3.我们还可以修改a.value = 2，再执行a + b结果是4. 道理就是这么简单。let a = ref(0, () => a) 中，a的结果是一个如上结构的对象，所以参与运行是OK的，对a.value进行改造，就可以做依赖收集了。比如：

let c = computed(() => a + b)

由于上面式子中会调用a.value和b.value，所以可以知道c对a,b有依赖。下面是最关键的：

a = a + 1

对a重新赋值，此时a的数据类型发生了变化，从对象变成了数字。但是没有关系，在computed进行依赖收集时，我们已经得到了一个计算公式：

c = (() => a)() + (() => b)()

也就是说，无论a, b是什么数据类型，计算后得到的c的结果是确定的。而关键的问题在于，一旦a丢失了object类型，就没有办法依靠vue的响应式设计完成响应式效果。此时，脏检查就来了。

  • 用callback包装handle（效果类似computed，主要做依赖收集）: handle = callback(() => a = a + 1)
  • 执行handle时，a.value被收集，代表handle函数有可能对a产生副作用，每次执行handle，可能收集到的ref变量不同，由if...else决定，根据这个情况，还可以做一些优化
  • 当handle被调用结束时，对收集到的所有依赖进行检查，检查依据是上一个值和这一次的() => a结果
  • 当发现值不相等时，表示依赖被更新了，此时回溯所有computed，如果发现对a有依赖，那么对应computed属性需要被更新

和angularjs的脏检查不同，因为这里我可以明确知道自己依赖了哪些变量，所以我做的检查范围会小很多。而且由于nextTick机制的存在，脏检查也仅限于数据层面，不会触发DOM的更新。

结束

你看，仅仅给ref加了第二个参数，就可以把这个issue给结了。但是，你可能会说，我() => a真不想写啊！！！要解决这个问题，最好的办法，就是你去做TC39主席，然后强推PrimitiveProxy，并且让Proxy完全适用于PrimitiveProxy，这下世界安静了。

10:30:49 已有0条回复
评论