针对滚动监听的一个小有意思的api

针对JavaScript垃圾回收机制的深入学习

之前就一直在困惑，await 后面包的那一大群代码到底是怎么个处理，闲下来了，这就学习一波

async和await是generator和Promise的语法糖，本质上是是将 Generator 函数和自动执行器，包装在一个函数里。

在做关于事件循环的分享时，注意到了这两种方式的调用结果在宏任务和微任务的执行方面有差别，特此学习记录一下

梳理Vue2底层执行流程

直观上来说，我仍然认为opacity与回流/重排没有半毛钱关系，但chrome控制台的性能分析报告显示确确实实出现了布局相关的渲染流程，但似乎是不确定的，存在某些契机。这太反直觉了，网上的资料也没有特别正确且直观的说明。所以下面只能根据个人推测来理解这个现象

牢记之所以使用 opacity 和 transform 等元素，最终是为了尽可能降低浏览器的计算成本，这一理论是正确的。

结论是，关于opacity的测试分为三种情况，分别是：

1. 触发回流（Layout）=>重绘（Paint）=>合成（Composite Layers）
2. 跳过回流和重绘，直接合成处理
3. 触发重绘=>合成

案例如下

TypeScript里的类型兼容性是基于结构类型系统的，只要二者的结构组成相同，就认为二者属于统一类型

1
2
3
4
5
6
7
8
9

interface Pet {
  name: string;
}
class Dog {
  name: string;
}
let pet: Pet;
// OK, because of structural typing
pet = new Dog();

三斜线指令是包含单个XML标签的单行注释。 注释的内容会做为编译器指令使用

仅可放在包含它的文件的最顶端。一个三斜线指令前面只能出现单行或多行注释，包括其他的三斜线指令。否则被当为普通注释

/// <reference path="..." />

用于声明文件间的依赖

当使用–out或–outFile时，它也可以做为调整输出内容顺序的一种方法。 文件在输出文件内容中的位置与经过预处理后的输入顺序一致

预处理输入文件

编译器通过预处理解析所有三斜线指令，将额外的文件加到编译过程中。

过程从一些根文件开始，它们在命令行中指定的文件或是tsconfig.json中的files列表里的文件。这些根文件按指定的顺序预处理。在一个文件被加入列表前，它包含的所有三斜线引用都要被处理，还有它们包含的目标。 三斜线引用以它们在文件里出现的顺序，使用深度优先的方式解析

一个三斜线引用路径是相对于包含它的文件的，如果不是根文件

错误

引用不存在的文件会报错。 一个文件用三斜线指令引用自己会报错。

使用 –noResolve

三斜线引用会被忽略；它们不会增加新文件，也不会改变给定文件的顺序

/// <reference types="..." />

指令声明了对某个包的依赖。

对这些包的名字的解析与在import语句里对模块名的解析类似。 可以简单地把三斜线类型引用指令当做import声明的包

仅当在你需要写一个d.ts文件时才使用这个指令。

当且仅当 结果文件中使用了引用的包里的声明时才会在生成的声明文件里添加/// <reference types="..." />语句

若要在.ts文件里声明一个对@types包的依赖，使用–types命令行选项或在tsconfig.json里指定

/// <reference no-default-lib="true"/>

把一个文件标记成 默认库。在lib.d.ts文件和它不同的变体的顶端看到这个注释

这个指令告诉编译器在编译过程中 不要 包含这个默认库（比如，lib.d.ts）。 这与在命令行上使用--noLib相似

当传递了--skipDefaultLibCheck时，编译器只会忽略检查带有/// <reference no-default-lib="true"/>的文件

/// <amd-module />

指令允许给编译器传入一个可选的模块名

1
2
3

///<amd-module name='NamedModule'/>
export class C {
}

这会将NamedModule传入到AMD define函数里

一种嵌入式的类似XML的语法。 它可以被转换成合法的JavaScript。常见的有React，博客所用到的库为inferno也是jsx。

枚举可以清晰地表达意图或创建一组有区别的用例。TypeScript支持数字的和基于字符串的枚举