Method trigger

lib/watcher.ts:47–84

()

  // 触发依赖
  public trigger() {
    if (this.dep.size) {
      // forEach每次循环都会调用函数，但是有js引擎层面（解释器）的优化
      this.dep.forEach((cb, path) => {
        cb();
        this.oldValMap.delete(path);
      });
      this.dep.clear();

      // for (const [path, cb] of this.dep.entries()) {
      //   cb();
      //   this.oldValMap.delete(path);
      // }

      /**
        不使用 for of 原因：

        一方面for of 内部循环调用迭代器接口（entries()方法实际上返回的就是迭代器，entries()比values()方法更慢），原理类似这样：
        // 遍历迭代器
        const iterator = this.dep[Symbol.iterator](); // 获取Map的迭代器接口（迭代器为各种不同的数据结构提供统一的访问机制）
        while (true) {
          const item = iterator.next();
          if (item.done) break;
          ... // 执行功能代码
        }
        但是具体实现可能要比这复杂的多，单纯使用 while 仅遍历 values() 的时候，上面方法是比forEach（key，value都会处理）快的，
        (while遍历values()更快，但是遍历entries()比forEach慢，所以使用forEach，另外while遍历迭代器可读性较差)
        而for of 仅遍历values()时也比forEach慢，所以js对于遍历迭代器的执行效率似乎并不高。

        ...运算符也是同理，一样是通过遍历迭代器实现，性能也一般，例如原生call是比apply快的（以前，或者某些低版本浏览器，现在差距不大了，
        据说是因为apply参数是数组，内部实现时需要处理这个数组有额外消耗），call(this, a, b, c)本来是比apply(this, [a, b, c])性能高或者持平的，
        但是如果非要用call(this, ...[a, b, c])，那就有点画蛇添足了，强行多出来一个遍历迭代器的工作，性能直接变low

        另一方面，解构也会消耗一定性能（其实内部也是遍历迭代器接口按顺序获取对应的值进行赋值，比正常取值慢2-3倍），所以此处使用forEach，
        仅针对数组解构，对象解构还是通过属性取值，只是换了种写法而已，性能一致。
      */
    }
  };

  // 更新被监听的响应式对象，触发响应式对象的set，收集被监听路径的依赖
  public updateWatchedData(path: string, newVal: any) {