【TypeScript 演化史 -- 3】标记联合类型 与 never 类型

作者：Marius Schulz
译者：前端小智
来源：Marius Schulz

你知道的越多，你不知道的越多

点赞再看，养成习惯

本文 GitHub https://github.com/qq44924588... 上已经收录，更多往期高赞文章的分类，也整理了很多我的文档，和教程资料。欢迎Star和完善，大家面试可以参照考点复习，希望我们一起有点东西。

TypeScript 2.0 实现了一个相当有用的功能：标记联合类型，您可能将其称为 sum 类型或与其他编程语言区别开的联合类型。 标记联合类型是其成员类型都定义了字面量类型的区分属性的联合类型。

上面的讲的是理论性的，来几个例子看看更贴切。

使用标记的联合类型构建付款方式

假设咱们为系统用户可以选择的以下支付方式建模

• Cash (现金)
• PayPal 与给定的电子邮件地址
• Credit card 带有给定卡号和安全码

对于这些支付方法，咱们可以创建一个 TypeScript 接口

interface Cash {
  kind: "cash";
}

interface PayPal {
  kind: "paypal",
  email: string;
}

interface CreditCard {
  kind: "credit";
  cardNumber: string;
  securityCode: string;
}

注意，除了必需的信息外，每种类型都有一个 kind 属性，即所谓的判别属性。这里每种情况都是字符串字面量类型。

现在定义一个 PaymentMethod 类型，它是我们刚才定义的三种类型的并集。通过这种方式，用声明 PaymentMethod 每个变量， 必须具有给定的三种组成类型中的一种：

type PaymentMethod = Cash | PayPal | CreditCard;

现在我们的类型已经就绪，来编写一个函数来接受付款方法并返回一个读得懂的话语：

function describePaymentMethod(method: PaymentMethod) {
  switch (method.kind) {
    case "cash":
      // Here, method has type Cash
      return "Cash";

    case "paypal":
      // Here, method has type PayPal
      return `PayPal (${method.email})`;

    case "credit":
      // Here, method has type CreditCard
      return `Credit card (${method.cardNumber})`;
  }
}

首先，该函数包含的类型注释很少，method 参数仅包含一个。除此之外，函数基本是纯 ES2015 代码。

在 switch 语句的每个 case 中，TypeScript 编译器将联合类型缩小到它的一个成员类型。例如，当匹配到 "paypal"，method 参数的类型从 PaymentMethod 缩小到 PayPal。因此，咱们可以访问 email 属性，而不必添加类型断言。

本质上，编译器跟踪程序控制流以缩小标记联合类型。除了 switch 语句之外，它还要考虑条件以及赋值和返回的影响。

function describePaymentMethod(method: PaymentMethod) {
  if (method.kind === "cash") {
    // Here, method has type Cash
    return "Cash";
  }

  // Here, method has type PayPal | CreditCard

  if (method.kind === "paypal") {
    // Here, method has type PayPal
    return `PayPal (${method.email})`;
  }

  // Here, method has type CreditCard
  return `Credit card (${method.cardNumber})`;
}

控制流的类型分析 使得使用标记联合类型非常顺利。使用最少的 TypeScript 语法开销，咱可以编写几乎纯 JS，并且仍然可以从类型检查和代码完成中受益。

使用标记联合类型构建 Redux 操作

标记联合类型真正发挥作用的用例是在 TypeScript 应用程序中使用 Redux 时。 编写一个事例，其中包括一个模型，两个 actions 和一个 Todo 应用程序的 reducer。

以下是一个简化的 Todo 类型，它表示单个 todo。这里使用 readonly 修饰符为了防止属性被修改。

interface Todo {
  readonly text: string;
  readonly done: boolean;
}

用户可以添加新的 todos 并切换现有 todos 的完成状态。根据这些需求，咱们需要两个 Redux 操作，如下所示：

interface AddTodo {
  type: "ADD_TODO";
  text: string;
}

interface ToggleTodo {
  type: "TOGGLE_TODO";
  index: number
}

与前面的示例一样，现在可以将Redux操作构建为应用程序支持的所有操作的联合

type ReduxAction = AddTodo | ToggleTodo;

在本例中，type 属性充当判别属性，并遵循Redux中常见的命名模式。现在添加一个与这两个action 一起工作的 Reducer：

function todosReducer(
  state: ReadonlyArray = [],
  action: ReduxAction
): ReadonlyArray {
  switch (action.type) {
    case "ADD_TODO":
      // action has type AddTodo here
      return [...state, { text: action.text, done: false }];

    case "TOGGLE_TODO":
      // action has type ToggleTodo here
      return state.map((todo, index) => {
        if (index !== action.index) {
          return todo;
        }

        return {
          text: todo.text,
          done: !todo.done
        };
      });

    default:
      return state;
  }
}

同样，只有函数签名包含类型注释。代码的其余部分是纯 ES2015，而不是特定于 TypeScript。

我们遵循与前面示例相同的逻辑。基于 Redux 操作的 type 属性，我们在不修改现有状态的情况下计算新状态。在 switch 语句的情况下，我们可以访问特定于每个操作类型的 text 和 index 属性，而不需要任何类型断言。

never 类型

TypeScript 2.0 引入了一个新原始类型 never。never 类型表示值的类型从不出现。具体而言，never 是永不返回函数的返回类型，也是变量在类型保护中永不为 true 的类型。

这些是 never 类型的确切特征，如下所述：

• never 是所有类型的子类型并且可以赋值给所有类型。
• 没有类型是 never 的子类型或能赋值给 never（never类型本身除外）。
• 在函数表达式或箭头函数没有返回类型注解时，如果函数没有 return 语句，或者只有 never 类型表达式的 return 语句，并且如果函数是不可执行到终点的（例如通过控制流分析决定的），则推断函数的返回类型是 never。
• 在有明确 never 返回类型注解的函数中，所有 return 语句（如果有的话）必须有 never 类型的表达式并且函数的终点必须是不可执行的。

听得云里雾里的，接下来，用几个例子来讲讲 never 这位大哥。

永不返回的函数

下面是一个永不返回的函数示例：

// Type () => never
const sing = function() {
  while (true) {
    console.log("我就是不返回值，怎么滴！");
    console.log("我就是不返回值，怎么滴！");
    console.log("我就是不返回值，怎么滴！");
    console.log("我就是不返回值，怎么滴！");
    console.log("我就是不返回值，怎么滴！");
    console.log("我就是不返回值，怎么滴！");
  }
}

该函数由一个不包含 break 或 return 语句的无限循环组成，所以无法跳出循环。因此，推断函数的返回类型是 never。

类似地，下面函数的返回类型被推断为 never

// Type (message: string) => never
const failwith = (message: string) => {
  throw new Error(message);
};

TypeScript 推断出 never 类型，因为该函数既没有返回类型注释，也没有可到达的端点(由控制流分析决定)。

不可能有该类型的变量

另一种情况是，never 类型被推断为从不为 ture。在下面的示例中，我们检查 value 参数是否同时是字符串和数字，这是不可能的。

function impossibleTypeGuard(value: any) {
  if (
    typeof value === "string" &&
    typeof value === "number"
  ) {
    value; // Type never
  }
}

这个例子显然是过于作，来看一个更实际的用例。下面的示例展示了 TypeScript 的控制流分析缩小了类型守卫下变量的联合类型。直观地说，类型检查器知道，一旦咱们检查了 value 是字符串，它就不能是数字，反之亦然

function controlFlowAnalysisWithNever(
  value: string | number
) {
  if (typeof value === "string") {
    value; // Type string
  } else if (typeof value === "number") {
    value; // Type number
  } else {
    value; // Type never
  }
}

注意，在最后一个 else 分支中，value 既不能是字符串，也不能是数字。在这种情况下，TypeScript 推断出 never 类型，因为咱们已经将 value 参数注解为类型为 string | number，也就是说，除了string 或 number, value 参数不可能有其他类型。

一旦控制流分析排除了 string 和 number 作为 value 类型的候选项，类型检查器就推断出never 类型，这是惟一剩下的可能性。但是，咱们也就不能对 value 做任何有用的事情，因为它的类型是 never，所以咱们的编辑器工具不会显示自动显示提示该值有哪些方法或者属性可用。

never 和 void 之间的区别

你可能会问，为什么 TypeScript 已经有一个 void 类型为啥还需要 never 类型。虽然这两者看起来很相似，但它们是两个不同的概念：

没有显式返回值的函数将隐式返回 undefined 。虽然我们通常会说这样的函数“不返回任何东西”，但它会返回。在这些情况下，我们通常忽略返回值。这样的函数在 TypeScript 中被推断为有一个 void 返回类型。

具有 never 返回类型的函数永不返回。它也不返回 undefined。该函数没有正常的完成，这意味着它会抛出一个错误，或者根本不会完成运行。

函数声明的类型推断

关于函数声明的返回类型推断有一个小问题。咱们前面列出的几条 never 特征，你会发现下面这句话：

在函数表达式或箭头函数没有返回类型注解时，如果函数没有return语句，或者只有never类型表达式的return语句，并且如果函数是不可执行到终点的（例如通过控制流分析决定的），则推断函数的返回类型是never。

它提到了函数表达式和箭头函数，但没有提到函数声明。也就是说，为函数表达式推断的返回类型可能与为函数声明推断的返回类型不同：

// Return type: void
function failwith1(message: string) {
  throw new Error(message);
}

// Return type: never
const failwith2 = function(message: string) {
  throw new Error(message);
};

这种行为的原因是向后兼容性，如下所述。如果希望函数声明的返回类型 never ，则可以对其进行显式注释：

function failwith1(message: string): never {
  throw new Error(message);
}

代码部署后可能存在的BUG没法实时知道，事后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具 Fundebug。

原文：

https://mariusschulz.com/blog...

https://mariusschulz.com/blog...

交流

干货系列文章汇总如下，觉得不错点个Star，欢迎 加群 互相学习。

https://github.com/qq449245884/xiaozhi

因为篇幅的限制，今天的分享只到这里。如果大家想了解更多的内容的话，可以去扫一扫每篇文章最下面的二维码，然后关注咱们的微信公众号，了解更多的资讯和有价值的内容。

每次整理文章，一般都到2点才睡觉，一周4次左右，挺苦的，还望支持，给点鼓励