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

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

以下資料是您可能在程式碼庫中找到的一些資料的範(fàn)例：

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ù)組或某種以客戶為中心的信息，具有嵌套值，可幫助填充詳細(xì)說明各種信息的表格、彈出窗口和卡片。

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

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

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

const stringSchema = z.string();

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

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

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

然而這也有其自身的缺陷；如果我希望覆蓋的值本身就是一個物件或陣列怎麼辦？然後，我必須手動輸入該功能之前所需的每一行才能繼續(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 將允許使用者指定他們選擇的模式，然後提供適當(dāng)?shù)母矊憗K傳回一個使用者物件！當(dāng)然，我們希望正確考慮數(shù)組以及單一物件。為此，對傳入的覆蓋類型進行簡單的類型檢查就足夠了：

const stringSchema = z.string();

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

上面的程式碼實際上與之前相同，但現(xiàn)在它在內(nèi)部封裝了解析，因此使用者不必手動執(zhí)行此操作或了解有關(guān) Zods 解析方法的詳細(xì)資訊。正如您透過閱讀包含的if/else 語句可能猜到的那樣，我們還透過使用遞歸建構(gòu)器函數(shù)來解決巢狀物件和陣列的保存問題，該函數(shù)解析每個值並傳回Zod 模式中指定的預(yù)設(shè)值。 ??>

上面的內(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

當(dāng)向建構(gòu)器提供preserveNestedDefaults配置選項時，使用者可以保留巢狀物件或陣列中的鍵值對！這解決了用戶覆蓋不是像字串這樣的原始類型的鍵的問題，而是一種更複雜的類型，並保留所有值減去我們選擇覆蓋的值。

這已經(jīng)是一篇相當(dāng)長的文章了，所以讓我們以我們所有努力工作的結(jié)果來結(jié)束吧。讓我們回顧一下第一個模擬，以及如何使用 zodObjectBuilder 來寫它。首先讓我們定義我們的類型和預(yù)設(shè)值，並將結(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

上述實作將使用所有預(yù)設(shè)值傳回單一物件！但我們可以做得更好，我們現(xiàn)在可以（借助一些重載定義和內(nèi)部解析）來建立物件數(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ù)組將是完整的預(yù)設(shè)值，並覆蓋交付狀態(tài)！希望這示範(fàn)了 zodObjectBuilder 函數(shù)如何最大限度地減少基於可靠的類型安全模式建立新模擬所需的工作。

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

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