如果您是前端工程師，您可能遇到過這樣的情況：您被要求在服務(wù)后端部分的 API 之前開始實現(xiàn)某個功能功能存在。工程師通常會轉(zhuǎn)向模擬來實現(xiàn)并行開發(fā)（這意味著該功能的前端和后端部分是并行開發(fā)的）。

然而，Mocking 可能會帶來一些缺點。第一個也是最明顯的一點是模擬可能會偏離實際實現(xiàn)，導(dǎo)致它們不可靠。第二個問題是模擬通常很冗長；對于包含大量數(shù)據(jù)的模擬，可能不清楚某個模擬響應(yīng)實際上在模擬什么。

以下數(shù)據(jù)是您可能在代碼庫中找到的一些數(shù)據(jù)的示例：

type Order = {
  orderId: string;
  customerInfo: CustomerInfo; // omitted these types for brevity
  orderDate: string;
  items: OrderItem[];
  paymentInfo: PaymentInfo;
  subtotal: number;
  shippingCost: number;
  tax: number;
  totalAmount: number;
  status: 'pending' | 'processing' | 'shipped' | 'delivered' | 'cancelled';
  trackingNumber: string | null;
};

const mockOrders: Order[] = [
  {
    orderId: "ORD-2024-001",
    customerInfo: {
      id: "CUST-1234",
      name: "Alice Johnson",
      email: "alice.j@email.com",
      shippingAddress: {
        street: "123 Pine Street",
        city: "Portland",
        state: "OR",
        zipCode: "97201",
        country: "USA"
      }
    },
    orderDate: "2024-03-15T14:30:00Z",
    items: [
      {
        productId: "PROD-789",
        name: "Organic Cotton T-Shirt",
        quantity: 2,
        pricePerUnit: 29.99,
        color: "Navy",
        size: "M"
      },
      {
        productId: "PROD-456",
        name: "Recycled Canvas Tote",
        quantity: 1,
        pricePerUnit: 35.00,
        color: "Natural"
      }
    ],
    paymentInfo: {
      method: "credit_card",
      status: "completed",
      transactionId: "TXN-88776655"
    },
    subtotal: 94.98,
    shippingCost: 5.99,
    tax: 9.50,
    totalAmount: 110.47,
    status: "shipped",
    trackingNumber: "1Z999AA1234567890"
  },
  // Imagine more objects here, with various values changed...
];

我每天使用的數(shù)據(jù)看起來很像這樣。訂單數(shù)組或某種以客戶為中心的信息，具有嵌套值，可幫助填充詳細說明各種信息的表格、彈出窗口和卡片。

作為一名負責(zé)維護嚴重依賴此類模擬的應(yīng)用程序的工程師，您可能會問“響應(yīng)模擬中的這個特定對象是什么？”。我經(jīng)常發(fā)現(xiàn)自己滾動瀏覽數(shù)百個示例，就像上面的示例一樣，但不確定每個對象的用途是什么。

隨著我對自己作為工程師的身份越來越有信心，我給自己下定決心要解決上述問題；如果每個模擬都可以更輕松地展示其目的怎么辦？如果工程師只需要編寫他們打算模擬的行怎么辦？

在使用一些代碼和一個名為 Zod 的庫時，我發(fā)現(xiàn)了以下稱為 parse 的方法，它嘗試根據(jù)已知類型驗證傳入數(shù)據(jù)：

const stringSchema = z.string();

stringSchema.parse("fish"); // => returns "fish"
stringSchema.parse(12); // throws error

這是一個靈光乍現(xiàn)的時刻； Zod 文檔中的這個小例子正是我一直在尋找的！如果解析方法可以接受一個值并返回它，那么如果我傳入一個值，我就會得到它。我也已經(jīng)知道我可以為 Zod 模式定義默認值。如果傳遞一個空對象將返回一個完整的對象及其值怎么辦？你瞧，確實如此；我可以在 Zod 模式上定義默認值，并返回默認值：

const UserSchema = z.object({
  id: z.string().default('1'),
  name: z.string().default('Craig R Broughton'),
  settings: z.object({
    theme: z.enum(['light', 'dark']),
    notifications: z.boolean()
  }).default({
    theme: 'dark',
    notifications: true,
  })
});

const user = UserSchema.parse({}) // returns a full user object

現(xiàn)在我有了一種生成對象的方法，但它仍然不是我想要的。我真正想要的是一種僅寫下我正在“嘲笑”的確切行的方法。一個簡單的解決方案可能如下所示：

const UserSchema = z.object({
id: z.string().default('1'),
name: z.string().default('Craig R Broughton'),
settings: z.object({
  theme: z.enum(['light', 'dark']),
  notifications: z.boolean()
}).default({
  theme: 'dark',
  notifications: true,
})
});


const user = UserSchema.parse({})
const overridenUser = {...user, ...{
  name: "My new name",
  settings: {}, // I would need to write every key:value for settings :(
} satisfies Partial<z.infer<typeof UserSchema>>} // overrides the base object

然而這也有其自身的缺陷；如果我希望覆蓋的值本身就是一個對象或數(shù)組怎么辦？然后，我必須手動輸入該功能之前所需的每一行才能繼續(xù)工作并按預(yù)期被嘲笑，這違背了我們正在進行的解決方案的目的。

很長一段時間以來，這就是我所得到的，直到最近我再次嘗試改進上述內(nèi)容。第一步是定義“API”；我希望我的用戶如何與此功能交互？

type Order = {
  orderId: string;
  customerInfo: CustomerInfo; // omitted these types for brevity
  orderDate: string;
  items: OrderItem[];
  paymentInfo: PaymentInfo;
  subtotal: number;
  shippingCost: number;
  tax: number;
  totalAmount: number;
  status: 'pending' | 'processing' | 'shipped' | 'delivered' | 'cancelled';
  trackingNumber: string | null;
};

const mockOrders: Order[] = [
  {
    orderId: "ORD-2024-001",
    customerInfo: {
      id: "CUST-1234",
      name: "Alice Johnson",
      email: "alice.j@email.com",
      shippingAddress: {
        street: "123 Pine Street",
        city: "Portland",
        state: "OR",
        zipCode: "97201",
        country: "USA"
      }
    },
    orderDate: "2024-03-15T14:30:00Z",
    items: [
      {
        productId: "PROD-789",
        name: "Organic Cotton T-Shirt",
        quantity: 2,
        pricePerUnit: 29.99,
        color: "Navy",
        size: "M"
      },
      {
        productId: "PROD-456",
        name: "Recycled Canvas Tote",
        quantity: 1,
        pricePerUnit: 35.00,
        color: "Natural"
      }
    ],
    paymentInfo: {
      method: "credit_card",
      status: "completed",
      transactionId: "TXN-88776655"
    },
    subtotal: 94.98,
    shippingCost: 5.99,
    tax: 9.50,
    totalAmount: 110.47,
    status: "shipped",
    trackingNumber: "1Z999AA1234567890"
  },
  // Imagine more objects here, with various values changed...
];

上面的 API 將允許用戶指定他們選擇的模式，然后提供適當?shù)母采w并返回一個用戶對象！當然，我們希望正確考慮數(shù)組以及單個對象。為此，對傳入的覆蓋類型進行簡單的類型檢查就足夠了：

const stringSchema = z.string();

stringSchema.parse("fish"); // => returns "fish"
stringSchema.parse(12); // throws error

上面的代碼實際上與之前相同，但是現(xiàn)在它在內(nèi)部封裝了解析，因此用戶不必手動執(zhí)行此操作或了解有關(guān) Zods 解析方法的詳細信息。正如您通過閱讀包含的 if/else 語句可能猜到的那樣，我們還通過使用遞歸構(gòu)建器函數(shù)來解決嵌套對象和數(shù)組的保存問題，該函數(shù)解析每個值并返回 Zod 模式中指定的默認值。 ??>

上面的內(nèi)容有點讓人費解，但結(jié)果是用戶可以執(zhí)行以下操作：

const UserSchema = z.object({
  id: z.string().default('1'),
  name: z.string().default('Craig R Broughton'),
  settings: z.object({
    theme: z.enum(['light', 'dark']),
    notifications: z.boolean()
  }).default({
    theme: 'dark',
    notifications: true,
  })
});

const user = UserSchema.parse({}) // returns a full user object

當向構(gòu)建器提供preserveNestedDefaults配置選項時，用戶可以保留嵌套對象或數(shù)組中的鍵值對！這解決了用戶覆蓋不是像字符串這樣的原始類型的鍵的問題，而是一種更復(fù)雜的類型，并保留所有值減去我們選擇覆蓋的值。

這已經(jīng)是一篇相當長的文章了，所以讓我們以我們所有努力工作的結(jié)果來結(jié)束吧。讓我們回顧一下第一個模擬，以及如何使用 zodObjectBuilder 編寫它。首先讓我們定義我們的類型和默認值，并將結(jié)果模式傳遞到 zodObjectBuilder 中：

const UserSchema = z.object({
id: z.string().default('1'),
name: z.string().default('Craig R Broughton'),
settings: z.object({
  theme: z.enum(['light', 'dark']),
  notifications: z.boolean()
}).default({
  theme: 'dark',
  notifications: true,
})
});


const user = UserSchema.parse({})
const overridenUser = {...user, ...{
  name: "My new name",
  settings: {}, // I would need to write every key:value for settings :(
} satisfies Partial<z.infer<typeof UserSchema>>} // overrides the base object

上述實現(xiàn)將使用所有默認值返回單個對象！但我們可以做得更好，我們現(xiàn)在可以（借助一些重載定義和內(nèi)部解析）創(chuàng)建對象數(shù)組，非常適合模擬 API 響應(yīng)的用例：

const UserSchema = z.object({
  id: z.string().default('1'),
  name: z.string().default('Craig R Broughton'),
  settings: z.object({
    theme: z.enum(['light', 'dark']),
    notifications: z.boolean()
  }).default({
    theme: 'dark',
    notifications: true,
  })
});

const user = zodObjectBuilder({
  schema: UserSchema,
  overrides: { name: 'My new name', settings: { theme: 'dark' } } // setting is missing the notifications theme :(
}); // returns a full user object with the overrides

上面輸出的訂單數(shù)組將是完整的默認值，并覆蓋交付狀態(tài)！希望這演示了 zodObjectBuilder 函數(shù)如何最大限度地減少基于可靠的類型安全模式創(chuàng)建新模擬所需的工作。

通過這個小演示，我們已經(jīng)完成了第一篇文章的結(jié)尾:) 我希望您喜歡閱讀這段探索改進模擬的旅程。 zodObjectBuilder 仍在構(gòu)建中，但它很好地滿足了我最小化模擬對象的需求。如果您想嘗試當前版本，可以在 https://www.npmjs.com/package/@crbroughton/ts-utils 找到它，其中包含該功能。

以上是我如何嘗試用 Zod 改進模擬的詳細內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！