Eslint

Bug 变量传递 class

通过将一个 class 传递给一个变量，该变量无法被 eslint 识别为 class：
https://github.com/typescript-eslint/typescript-eslint/issues/1485
image.png

Typescript

Intersection type

image.png

同名冲突

interface 更偏向继承的思想

Interfaces vs. Intersections We just looked at two ways to combine types which are similar, but are actually subtly different. With interfaces, we could use an extends clause to extend from other types, and we were able to do something similar with intersections and name the result with a type alias. The principle difference between the two is how conflicts are handled, and that difference is typically one of the main reasons why you’d pick one over the other between an interface and a type alias of an intersection type.

interface 同名冲突表现为 覆盖
虽然会覆盖，但是 ts 仍旧会提示
也就是 ts 会检查 interface 时同名属性的 subtyping 关系
image.png

  1. interface One {
  2.   name: string
  3. }
  4. interface Two extends One{
  5.   name: number
  6. }
  8. const testa: Two = {
  9.   name: '11', // number
  10. }

type Intersections 同名冲突表现为 合并
如这里的 string 与 number，由于不存在既是 number 又是 string 的情况，所以最终为 never

  1. type One1 = {
  2.   name: string;
  3. }
  4. type Two1 = {
  5.   name: number;
  6. }
  8. const testa1: One1 & Two1 = {
  9.   name: '11', // never
  10. };

对于 OOP，能使用 interface 的场景，尽量使用 interface，因为 type 存在合并出错的可能。

由于 interface 只可用于抽象定义，所以对一个 接口 的 实现 还是要通过 class 来进行，如这里的 DefaultEngine 则代表了对 Engine 这一 接口 的 默认实现：

  1. interface Engine {}
  2. // 如需要默认实现，使用 DefaultXX class 来做最就基本的接口实现
  3. class DefaultEngine implements Engine {}
  4. // 但由于 Ts 类不支持多重继承，所以 细粒度化 的 多接口组合，还是得先 抽象组合 后，再进行 基本实现。
  5. // 不是很好用

对于 OOP 来说，接口的存在意义就是为了解耦，且接口定义的内容越少越好。

开发中错误的做法就是 从实现类中提取接口（或直接继承实现类来获得某些功能），应该 先定义服务方与消费方的接口，再进行实现。在未使用（需要实现）时，只做抽象接口的组合（interface 互相 extends 实现）。

另外，最好的 非继承组合方式，应该是装饰器，但至今 Ts 无法解决装饰器的类型检查:
https://github.com/microsoft/TypeScript/issues/4881
如果以下这段代码正常，世界将变得美好起来

  1. interface HasNewProperty {
  2.   newProperty: string;
  3. }
  5. function classDecorator<T extends { new (...args: any[]): {} }>(
  6.   constructor: T,
  7. ) {
  8.   return class extends constructor implements HasNewProperty {
  9.     newProperty = 'new property';
  11.     hello = 'override';
  12.   };
  13. }
  15. @classDecorator
  16. class Greeter {
  17.   property = 'property';
  19.   hello: string;
  21.   constructor(m: string) {
  22.     this.hello = m;
  23.   }
  24. }
  26. console.log(new Greeter('world'));
  28. // Alas, this line makes the compiler angry because it doesn't know
  29. // that Greeter now implements HasNewProperty
  30. console.log(new Greeter('world').newProperty);

Type

typescript 的函数重载

ts 的函数重载属于 Intersection type（交叉），不是 union type（联合）。也就是 几个函数的合体，而不是 几个函数中的一个。
因为 Typescript 始终是要编译成 js的，函数重载并不是真正的函数重载入（有多个函数），实际只有一个函数，所以是几个函数的合体。至于为什么要这么实现可以参考 Ts 官方的语言目标：
https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#goals
image.png
所以其实如果觉得重载的写法容易迷惑，可以采用简单的 Intersection type 也就是 xx & xx 的写法来代替。
_
另外，interface 的多函数写法，实际就是一个 intersection type ，感觉更合适的函数重载写法

  1.   interface A {
  2.     (arg: number): number;
  3.     (arg: string): string;
  4.   }

可以简单验证：
但是该方式会导致函数体本身的自查跳过，可能会出现问题，应该尽量避开。

  1.   interface A {
  2.     (arg: number): number;
  3.     (arg: string): string;
  4.   }
  6.   // type A = ((arg: number) => number) | ((arg: string) => string);
  8.   const a = function (arg: number | string) {
  9.     if (typeof arg === 'string') return arg;
  10.     return arg;
  11.   } as A; // ！注意这是一个特殊写法 丧失函数体内部自查，不安全
  13.   a({})

重载生效了：
image.png
自查失效了：
所以如果函数体参数复杂，返回值复杂的场景，还是老老实实采用 ts 的重载入写法吧，虽然繁琐
image.png