JSON至TypeScript：符合实际的类型

为什么手写字体会出现漂移

根据文档或记忆编写的接口往往是乐观的。他们标记存在的所有内容，假设可为空的字段始终存在，并悄悄地错过仅出现在高级帐户中的嵌套对象。然后TypeScript强制执行服务器从未承诺过的形状，并且第一个`undefined`在生产中而不是在编译时出现。从真实响应生成会颠倒该过程：编译器正在检查观察到的形状而不是希望的形状。

读取生成的文件

有用的转换在嵌套对象的键之后命名，保持数组元素类型完整，并显式表达不确定性。注意具有所有含义的三个标记：

                export interface Order {
  id: string;
  total: number;
  coupon?: string;            // absent in some responses
  shippedAt: string | null;   // present but null until shipped
  items: Array<OrderItem>;
}
              

`coupon?: string` 和`shippedAt: string | null` 之间的差异并不是表面上的。可选意味着密钥可以丢失； null 表示键没有值。 API 通常在同一个有效负载中执行这两项操作，并将它们合并在一起，将空检查推送到假定字符串的代码中。

使用多个样本

单个响应标志着所需的一切。粘贴两到三个响应（理想情况下，一个来自空帐户，一个来自完整帐户），可选键就会显示出来：任何样本中缺少的字段将变为 `?`，有时为空的字段将变为与 `null` 的并集。这是可用的最便宜的正确性升级，这就是当 API 更改时应该重新生成生成的类型而不是一次性写入的原因。

切勿让生成的界面成为 API 的唯一描述。保留架构或契约测试，这样服务器更改就会导致构建失败，而不是用户会话失败。

类型所属的位置

• 专用的 `types/` 或 `api/` 文件夹，不分散在组件中。
• 每个端点或每个资源一个文件，带有命名端点及其捕获日期的注释。
• 再生注释：哪个调用产生了有效负载，以便下一个人可以重复它。
• 获取层和组件都会使用导出，因此更改恰好会破坏一个位置。

开启严格模式

生成的类型只有在启用 `strict` 时才有效，因为这使得可选键在直接访问时成为实际错误。将生成的接口与获取边界处的 `unknown` 配对，并在使用前缩小：`JSON.parse` 返回 `any`，因此对生成的接口的强制转换应该是您已验证的点，而不是您希望的点。

从您不会上传的有效负载生成

API 响应是大多数开发人员处理的最敏感的JSON 账户数据、订单、代币。在浏览器中运行 JSON 到 TypeScript 转换意味着有效负载在本地进行解析并且永远不会传输，因此您可以粘贴真实的响应而无需先进行编辑，并且该工具可以保持离线工作。