前端权限管理方案之精确到按钮级别

在过去的几年里，TypeScript 语言除了增长用户之外几乎什么都没做。它已被许多 Web 开发人员评为最喜欢的语言。使用纯JavaScript 代码的前端工作变得越来越少。

但是，有时 TypeScript 并没有充分发挥其潜力。导致过多或使用过多any是最常见的错误之一。

在本文中，我们将看到5 个 TypeScript 库，这些库将增强您的 TypeScript 体验并增加您对其静态类型的信心。这些最小的库将提高开发人员的开发效率。

1、zod

TypeScript 的薄弱环节是仅在编译时验证。一旦它被解析和构建，所有类型都被删除。在以下情况下，这可能会导致出现一些错误：

• 编译器以一些假设信任开发人员（开发人员使用any, ts-expect-error, cast 等忽略类型检查…）
• 网络返回的 REST 模式与预期不同。

让我们看一个例子：

interface User {name: string;email: string; 
}
async function fetchUser(id: string): User {const url = `/users/${id}`;const response = await fetch(url);return (await response.json()) as User; 
} 
1
2
3
4

在上面的代码中，编译器认为请求将返回一个带有 name 和email属性的 JSONUser对象。如果结果不是这样，将在生产中出现bug。但不幸的是，这些bug只能在运行时找到原因。

我们可以定义一个模式，该zod模式可以在运行时进行验证。

让我们看看使用zod重构后的代码：

const UserSchema = z.object({name: z.string(),email: z.string(),
}); 
async function fetchUser(id: string) {const url = `/users/${id}`;const response = await fetch(url); // ✅如果校验不通过，可以通过日志抛出错误。return UserSchema.parse(await response.json());
} 
1
2
3
4

我们可以选择如何处理错误。在上面的示例中，UserSchema.parse将在运行时引发错误。

我们也可以选择不使用safeParse方法抛出错误。它仅适合在日志记录问题而不会破坏用户体验。

Zod 非常强大，我们还可以使用z.infer. 我们可以在整个代码中使用该方法。