Question

让我在开始这个问题时先说一下我对打字稿还不是很陌生，但是JavaScript开发人员却很长。

我有一个现有的JavaScript应用程序，希望将其转换为打字稿。在JavaScript应用程序中，它将进行rest API调用以获取数据，然后检查其是否存在，然后有条件地呈现该应用程序。在JavaScript中，我可以动态检查响应对象上是否存在Properties，并有条件地呈现它。在typescript中，它会引发错误，因为数据是任何类型，并且它不知道该属性是否存在。

在打字稿应用程序中，为所有API响应创建类型是否很常见，以便可以对其进行类型安全？使用node作为后端，我可以看到一个巨大的机会，您可以在其中共享后端和前端模型。我目前正在使用.net core作为后端，并且担心自己可能总是试图从实体框架模型中创建打字稿模型。

其他人是否在后端使用.net核心并在前端做出反应？您如何处理打字稿中的API响应？

Answer 1

我不能告诉您它是否常见，但是我们为每个端点编写json-schema文件。这些架构文件是：

用于验证请求正文并生成错误。
用于生成文档。
转换为打字稿类型，在前端和后端都使用。

Answer 2

我们使用与您相同的堆栈-.Net Core后端/反应前端-带有打字稿。我们处理该问题的方法是为后端发送给我们的对象创建类型，然后将您提到的动态检查器转换为user-defined type guards。

因此，粗略地说，对于服务器返回的各种数据传输对象，我们有一个类型/类型保护对，如下所示：

// type
export type SomeDto = { someKey: string; someOtherKey: number }
// type guard
export const isSomeDto = (returnedObj: any): returnedObj is SomeDto =>
  returnedObject.someKey && typeof returnedObj === "string"
  returnedObject.someOtherKey && tyepeof returnedObj === "number"

然后，我们在获取代码中基本上具有以下内容：

const someReturn = fetchDatafromApi(endpoint)
if isSomeDto(someReturn) {
  //now typescript will recognize someReturn as SomeDto
} else {
  // throw or otherwise handle the fact you have bad data from the
  // server
}

这样，您可以在运行时在javascript中进行动态检查，并在编译时键入安全性。这些防护并不是很有趣（您需要对它们进行单元测试），而且我想如果对象的可能数目更大，我们会选择一种更自动化的解决方案，例如@Evert回答。但是对于一些对象和现有的javascript验证器，这是在API返回值上进行键入的一种非常便捷的方法。

打字稿和REST API响应

2 个答案: