Zod를 사용하여 조롱을 개선하기 위해 노력한 방법

프론트엔드 엔지니어라면 백엔드 부분을 제공하는 API 이전에 기능 구현을 시작해야 하는 상황에 처해 있었을 것입니다. 기능이 존재합니다. 엔지니어는 병렬 개발을 가능하게 하기 위해 모의 작업을 수행하는 경우가 많습니다. 즉, 기능의 프런트엔드와 백엔드 부분이 모두 병렬로 개발된다는 의미입니다.

그러나 조롱에는 몇 가지 단점이 있을 수 있습니다. 첫 번째이자 가장 분명한 것은 모의 객체가 실제 구현에서 벗어나 신뢰할 수 없게 만들 수 있다는 것입니다. 두 번째 문제가 되는 문제는 mock이 종종 장황해질 수 있다는 것입니다. 많은 양의 데이터가 포함된 모의 응답의 경우 특정 모의 응답이 실제로 무엇을 모의하고 있는지 불분명할 수 있습니다.

아래 데이터는 코드 베이스에서 찾을 수 있는 일부 데이터의 예입니다.

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...
];

내가 매일 작업하는 데이터는 이런 느낌이 많이 들어요. 모든 종류의 정보가 자세히 설명된 테이블, 팝업 및 카드를 채우는 데 도움이 되는 중첩된 값을 특징으로 하는 주문 배열 또는 일종의 고객 중심 정보입니다.

이러한 모의 객체에 크게 의존하는 애플리케이션을 유지 관리하는 임무를 맡은 엔지니어라면 '모의 응답에서 이 특정 개체가 무엇인가요?'라고 질문할 수 있습니다. 저는 위와 같은 수백 개의 예시를 스크롤하면서 각 객체의 목적이 무엇인지 확신할 수 없는 경우가 종종 있었습니다.

엔지니어로서의 내 자신에 대한 확신이 커짐에 따라 위의 문제를 해결하는 임무를 맡게 되었습니다. 모든 모의 모형이 그 목적을 더 쉽게 표시할 수 있다면 어떨까요? 엔지니어가 조롱하려는 라인만 작성하면 어떻게 될까요?

일부 코드와 Zod라는 라이브러리를 가지고 놀다가 알려진 유형에 대해 수신 데이터의 유효성을 검사하는 구문 분석이라는 다음 메서드를 발견했습니다.

const stringSchema = z.string();

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

이것은 전구의 순간이었습니다. Zod 문서에 있는 이 작은 예는 제가 찾던 바로 그 예였습니다! 구문 분석 메서드가 값을 받아들이고 반환할 수 있는 경우 값을 전달하면 다시 가져옵니다. 또한 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

이제 객체를 생성할 수 있는 방법이 생겼지만 여전히 제가 찾던 것이 아니었습니다. 제가 정말 원했던 것은 제가 '조롱'한 대사를 만 정확하게 쓰는 방법이었습니다. 간단한 해결책은 다음과 같습니다.

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

그러나 여기에는 자체적인 결함이 있습니다. 재정의하려는 값 자체가 객체이거나 배열이면 어떻게 되나요? 그런 다음 해당 기능이 계속 작동하고 예상대로 조롱되기 위해 이전에 필요했던 각 줄을 수동으로 입력해야 했으며, 이는 진행 중인 솔루션의 목적에 어긋납니다.

아주 최근까지 위의 내용을 개선하기 위해 또 다른 노력을 하기 전까지는 이것이 제가 가진 한계였습니다. 첫 번째 단계는 '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를 사용하면 사용자는 자신이 선택한 스키마를 지정한 다음 적절한 재정의를 제공하고 사용자 개체를 반환할 수 있습니다. 물론 우리는 단일 객체뿐만 아니라 배열도 적절하게 설명하고 싶습니다. 이를 위해서는 들어오는 재정의 유형에 대한 간단한 유형 검사만으로 충분하다는 것이 입증되었습니다.

const stringSchema = z.string();

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

위 코드는 사실상 이전과 동일한 코드이지만 이제 내부적으로 구문 분석을 캡슐화하므로 사용자가 수동으로 캡슐화하거나 Zods 구문 분석 방법에 대한 자세한 정보를 알 필요가 없습니다. 포함된 if/else 문을 통해 짐작할 수 있듯이 각 값을 구문 분석하고 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

preservedNestedDefaults 구성 옵션을 빌더에 제공하면 사용자는 중첩된 객체 또는 배열 내에서 키 값 쌍을 보존할 수 있습니다! 이는 문자열과 같은 기본 유형이 아닌 더 복잡한 유형인 키를 사용자가 재정의하는 문제를 해결하며 재정의하기로 선택한 값을 제외한 모든 값을 유지합니다.

이미 꽤 많이 읽었으니 열심히 노력한 결과로 마무리하겠습니다. 첫 번째 모의 객체를 다시 살펴보고 zodObjectBuilder를 사용하여 이를 작성하는 방법을 살펴보겠습니다. 먼저 유형과 기본값을 정의하고 결과 스키마를 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

위 구현에서는 모든 기본값을 사용하여 단일 개체를 반환합니다! 하지만 그보다 더 나은 일을 할 수 있습니다. 이제 (몇 가지 오버로드 정의와 내부 구문 분석을 통해) 모의 API 응답 사용 사례에 완벽한 객체 배열을 생성할 수 있습니다.

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

위의 주문 배열은 배송 상태가 재정의된 전체 기본값으로 출력됩니다! 이것이 zodObjectBuilder 함수가 신뢰할 수 있는 유형 안전 스키마를 기반으로 새로운 모의 객체를 생성하는 데 필요한 노력을 최소화할 수 있는 방법을 보여주기를 바랍니다.

이 짧은 시연으로 첫 번째 기사가 끝났습니다 :) 모의 개선에 대한 탐색 여정을 재미있게 읽으셨기를 바랍니다. zodObjectBuilder는 아직 빌드 중이지만 모의 개체를 최소화하기 위해 내 요구 사항을 잘 충족하고 있습니다. 현재 버전을 사용해 보고 싶다면 해당 기능이 포함된 https://www.npmjs.com/package/@crbroughton/ts-utils에서 찾을 수 있습니다.

위 내용은 Zod를 사용하여 조롱을 개선하기 위해 노력한 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!