Yup 库中 nullable().required() 的类型推断问题解析

核心问题概述

在使用 Yup 进行表单验证时，开发者经常会遇到一个类型推断的特殊情况：当 schema 同时使用 nullable() 和 required() 方法时，TypeScript 的类型推断结果与实际的运行时行为存在差异。

典型场景分析

考虑以下常见的使用模式：

const validationSchema = object({
  test: string().nullable().required()
});

type FormData = InferType<typeof validationSchema>;

const DEFAULT_VALUES: FormData = {
  test: null // 这里会出现类型错误
};

在这个例子中，TypeScript 会报错提示 null 不能赋值给 string 类型，但实际上运行时验证是能够正常工作的 - 初始值可以是 null，但提交时会验证 null 不是有效值。

技术背景解析

这个问题源于 Yup 的类型定义实现方式：

1. nullable() 方法会将字段类型扩展为 T | null
2. required() 方法会移除 null 类型，返回 NonNullable<T>
3. 方法链的顺序影响了最终的类型推断结果

官方立场说明

Yup 维护者明确指出这是预期行为。在 Yup v1 版本中，required() 会覆盖 nullable() 的效果，因此不能同时使用这两个方法。这种设计决策反映了表单验证的常见需求 - 一个字段要么是可选的（允许 null），要么是必填的（不允许 null）。

实际解决方案建议

对于需要处理服务器可能返回 null 值的场景，推荐采用以下模式：

1. 分离输入和输出 schema：为服务器数据和表单数据分别定义不同的验证规则
2. 使用深度部分类型：通过 deepPartial 等方式复用 schema 定义
3. 类型转换层：在数据进入表单前进行预处理，将 null 转换为其他占位值

最佳实践示例

// 服务器数据 schema
const serverSchema = object({
  test: string().nullable()
});

// 表单数据 schema
const formSchema = object({
  test: string().required()
});

// 数据转换函数
function prepareFormData(serverData: InferType<typeof serverSchema>) {
  return {
    test: serverData.test || '' // 将 null 转换为空字符串
  };
}

这种模式既保持了类型安全，又符合业务逻辑需求，是处理这类边界情况的推荐做法。