在TypeScript中，当定义一个泛型函数以接受可配置的接口（例如，包含Zod验证器）时，确保在重写默认配置时仍能正确推断返回类型是一个常见挑战。本文将详细探讨如何通过利用TypeScript的泛型、条件类型以及Zod的`ZodType`，构建一个灵活且类型安全的函数，从而在自定义验证器时，精确地推断出解析后的数据结构，避免类型丢失为`any`。
在开发可扩展的插件或模块时，我们常常需要定义一个函数，它接受一个配置对象，其中包含一些默认值，并且允许用户通过泛型来覆盖这些默认值。一个典型的场景是使用Zod库来定义数据验证器。
考虑以下场景：我们有一个definePlugin函数，它接受一个实现PluginConfig接口的对象。这个接口可能包含一个可选的Zod验证器，并且我们希望提供一个默认的EmailValidator。当用户提供自定义验证器时，我们期望definePlugin的返回值能够准确地反映自定义验证器解析后的类型，而不是泛泛的any。
最初的实现可能会遇到以下问题：
以下是初始代码示例及其暴露的问题：
import { z } from 'zod'
export const EmailValidator = z.object({
email: z
.string({ required_error: 'auth.validation.email' })
.email({ message: 'auth.validation.email_format' })
})
// 初始问题：z.ZodType 是一个类型，直接使用可能不够精确
interface PluginConfig {
validator?: z.ZodType
}
// 初始问题：未正确继承 PluginConfig
interface DefaultPluginConfig {
validator?: typeof EmailValidator
}
const definePlugin = <T extends PluginConfig = DefaultPluginConfig>({
validator = EmailValidator
}: T) => {
return validator.parse({}) // 返回类型可能为 any
}
const test = definePlugin({})
// test.email 此时类型为 any
const CustomValidator = z.object({
email: z.string(),
username: z.string()
})
interface CustomConfig {
validator?: typeof CustomValidator
}
const test2 = definePlugin<CustomConfig>({
validator: CustomValidator
})
// test2.username 此时类型为 any为了解决上述问题，我们需要对PluginConfig接口和definePlugin函数的泛型签名进行优化，使其能够精确地捕获并推断出验证器及其解析后的数据类型。
首先，将PluginConfig接口本身也泛型化，使其能够持有具体的ZodType。这样，任何实现PluginConfig的类型都可以指定其内部validator的具体Zod类型。
import { z, ZodType } from "zod";
// 默认验证器
export const EmailValidator = z.object({
email: z.string().default("")
});
// 泛型化的 PluginConfig 接口
// T 约束为 ZodType，并默认为 EmailValidator 的类型
interface PluginConfig<T extends ZodType = typeof EmailValidator> {
validator?: T;
}这里，PluginConfig<T extends ZodType = typeof EmailValidator>表示PluginConfig接受一个类型参数T，该参数必须是ZodType的子类型，并且默认为EmailValidator的类型。这样，validator属性的类型就被精确地定义为T。
接下来，是definePlugin函数的关键优化。我们需要引入两个新的泛型参数来帮助类型推断：一个用于捕获配置中的验证器类型，另一个用于捕获该验证器解析后的数据类型。
const definePlugin = <
// T: 输入的配置类型，默认为包含 EmailValidator 的 PluginConfig
T extends PluginConfig = PluginConfig<typeof EmailValidator>,
// R: 从 T 中推断出 validator 的具体 ZodType
R = T extends PluginConfig<infer V> ? V : ZodType
>({
validator = EmailValidator
}: T): R extends ZodType<infer P> ? P : never => { // 返回类型推断
// 运行时执行解析，类型断言 as any 是因为 TypeScript 难以在编译时完全模拟 Zod 的运行时解析
return validator.parse({}) as any;
};让我们详细分解这个函数签名：
T extends PluginConfig = PluginConfig<typeof EmailValidator>:
R = T extends PluginConfig<infer V> ? V : ZodType:
(...): R extends ZodType<infer P> ? P : never:
return validator.parse({}) as any;:
现在，我们可以测试这个优化后的definePlugin函数，看看它是否能正确推断类型：
// 使用默认配置
const test = definePlugin({});
// test 的类型被正确推断为 { email: string }
console.log(test.email); // 正确访问
// 定义自定义验证器
const CustomValidator = z.object({
email: z.string().default(""),
username: z.string().default("")
});
// 定义自定义配置类型
type CustomConfig = PluginConfig<typeof CustomValidator>;
// 使用自定义配置
const test2 = definePlugin<CustomConfig>({
validator: CustomValidator
});
// test2 的类型被正确推断为 { email: string; username: string }
console.log(test2.username); // 正确访问
console.log(test2.email); // 正确访问通过上述示例，我们可以看到test和test2变量的类型都被TypeScript精确地推断出来，不再是any。
通过上述方法，我们成功地实现了一个高度类型安全的泛型函数，它允许用户覆盖默认配置中的验证器，同时确保返回值的类型能够被TypeScript正确推断。
核心要点：
这种模式在构建可扩展的、类型安全的库和框架时非常有用，特别是在处理配置对象和数据验证等场景。它使得代码更具可读性、可维护性，并大大减少了运行时可能出现的类型错误。
以上就是如何在TypeScript函数中重写接口并保持正确的返回类型的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告
收藏
收藏
收藏
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
776
