如何处理Schema中的可选属性？API请求场景实践问询

嘿，这个场景太常见了！其实完全不用为不同的API响应单独创建Schema，Normalizr本身就有很灵活的方式处理可选字段，给你几个实用方案：

1. 直接使用现有Schema（默认支持可选） #

Normalizr在解析响应时，会自动忽略那些你在Schema中定义但API返回里不存在的字段，不会抛出任何错误，也不会影响其他字段的归一化处理。

比如你现在定义的billSchema，不管API返回里有没有steps字段，都可以直接用：

• 如果响应里有steps，Normalizr会用stepSchema解析这个数组并归一化；
• 如果没有steps，它只会跳过这个字段，归一化后的结果里不会包含_embedded.steps，但其他字段（比如currentStep、latestText）依然会被正确处理。

这是最简单的方案，完全不需要修改现有代码。

2. 为可选字段设置默认值（如果需要） #

如果你希望即使steps字段不存在，归一化后的结果里也能保留这个属性（比如默认是空数组），可以用**自定义解析器（resolver）**来处理：

const billSchema = new schema.Entity('bills');
billSchema.define({
  _embedded: {
    currentStep: stepSchema,
    latestText: textSchema,
    steps: {
      // 当字段不存在时返回空数组
      resolver: (value) => value || [],
      schema: [stepSchema]
    }
  }
});

这样一来，不管API返回里有没有steps，归一化后的_embedded.steps都会是一个数组（要么是解析后的步骤数组，要么是空数组），避免后续代码处理undefined的麻烦。

3. 动态调整Schema（进阶用法） #

如果遇到更复杂的场景（比如某些字段的Schema需要根据响应动态变化），还可以在调用normalize方法时，通过第二个参数传入动态生成的Schema。不过你的场景里完全没必要用到这个，前面两个方案足够解决问题了。

总结一下：Normalizr的设计就是为了复用Schema，默认就支持可选字段，所以你现在的Schema已经能直接处理两种API响应了；如果需要默认值，加个resolver就行。

内容的提问来源于stack exchange，提问作者kud