Wie ich versucht habe, das Spotten mit Zod zu verbessern

Wenn Sie ein Frontend-Ingenieur sind, waren Sie wahrscheinlich in einer Situation, in der Sie mit der Implementierung einer Funktion vor der API beginnen mussten, die den Back-End-Teil davon bedient Funktion vorhanden. Ingenieure greifen oft auf Mocking zurück, um eine parallele Entwicklung zu ermöglichen (was bedeutet, dass sowohl der Front-End- als auch der Back-End-Teil der Funktion parallel entwickelt werden).

Verspottung kann jedoch einige Nachteile mit sich bringen. Das erste und offensichtlichste ist, dass Mocks von der tatsächlichen Implementierung abweichen können, was dazu führt, dass sie unzuverlässig sind. Ein zweites Problem besteht darin, dass Mocks oft ausführlich sein können; Bei Mocks, die viele Daten enthalten, kann es unklar sein, was eine bestimmte Mock-Antwort tatsächlich verspottet.

Die folgenden Daten sind ein Beispiel für einige Daten, die Sie möglicherweise in einer Codebasis finden:

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

Die Daten, mit denen ich jeden Tag arbeite, sehen in etwa so aus. Arrays von Bestellungen oder kundenorientierten Informationen mit verschachtelten Werten, die dabei helfen, Tabellen, Popups und Karten mit allen möglichen Informationen zu füllen.

Als Ingenieur, der mit der Wartung von Anwendungen beauftragt ist, die stark auf solche Mocks angewiesen sind, fragen Sie sich vielleicht: „Was ist dieses spezielle Objekt im Antwort-Mock?“ Ich habe mich oft dabei ertappt, wie ich durch Hunderte von Beispielen gescrollt habe, genau wie das obige, und mir nicht sicher war, welchen Zweck jedes Objekt hatte.

Da ich als Ingenieur selbstbewusster geworden bin, habe ich es mir zur Aufgabe gemacht, das oben genannte Problem zu lösen. Was wäre, wenn jeder Spott seinen Zweck leichter zeigen könnte? Was wäre, wenn ein Ingenieur nur die Zeilen schreiben müsste, die er verspotten wollte?

Während ich mit etwas Code und einer Bibliothek namens Zod herumgespielt habe, bin ich auf die folgende Methode namens parse gestoßen, die versucht, eingehende Daten anhand eines bekannten Typs zu validieren:

const stringSchema = z.string();

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

Das war ein Aha-Moment; Dieses kleine Beispiel in der Zod-Dokumentation war genau das, wonach ich gesucht hatte! Wenn die Parse-Methode einen Wert akzeptieren und zurückgeben könnte, würde ich ihn zurückbekommen, wenn ich einen Wert übergebe. Ich wusste auch bereits, dass ich Standardwerte für ein Zod-Schema definieren kann. Was wäre, wenn die Übergabe eines leeren Objekts ein vollständiges Objekt mit seinen Werten zurückgeben würde? Und siehe da, es geschah; Ich könnte Standardwerte in einem Zod-Schema definieren und die Standardwerte zurückgeben:

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

Jetzt hatte ich eine Möglichkeit, Objekte zu generieren, aber es war immer noch nicht ganz das, was ich suchte. Was ich wirklich wollte, war eine Möglichkeit, nur genau die Zeilen zu schreiben, über die ich mich lustig machte. Eine einfache Lösung könnte so aussehen:

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

Dies hat jedoch seine eigenen Mängel; Was passiert, wenn der Wert, den ich überschreiben möchte, selbst ein Objekt oder Array ist? Ich müsste dann jede Zeile manuell eingeben, die zuvor erforderlich war, damit diese Funktion weiterhin funktioniert und wie erwartet verspottet wird, was den Zweck unserer in Arbeit befindlichen Lösung zunichte macht.

Das war lange Zeit alles, was ich erreicht hatte, bis ich vor kurzem einen weiteren Versuch unternommen habe, das oben Gesagte zu verbessern. Der erste Schritt bestand darin, die „API“ zu definieren; Wie wollte ich, dass meine Benutzer mit dieser Funktionalität interagieren?

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

Die obige API würde es dem Benutzer ermöglichen, ein Schema seiner Wahl anzugeben, dann die entsprechenden Überschreibungen bereitzustellen und ein Benutzerobjekt zurückzugeben! Natürlich möchten wir sowohl Arrays als auch ein einzelnes Objekt ordnungsgemäß berücksichtigen. Zu diesem Zweck erwies sich eine einfache Typprüfung anhand des Typs der eingehenden Überschreibungen als ausreichend:

const stringSchema = z.string();

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

Das Obige ist praktisch derselbe Code wie zuvor, jedoch kapselt er das Parsing jetzt intern, sodass Benutzer dies nicht manuell tun oder detaillierte Informationen über die Parsing-Methode von Zod kennen müssen. Wie Sie beim Durchlesen der enthaltenen if/else-Anweisung vielleicht erraten haben, haben wir auch die Erhaltung verschachtelter Objekte und Arrays durch die Verwendung einer rekursiven Builder-Funktion gelöst, die jeden Wert analysiert und seine im Zod-Schema angegebenen Standardwerte zurückgibt.

Das oben Genannte ist ziemlich umfangreich, aber das Ergebnis ist, dass ein Benutzer Folgendes tun kann:

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

Wenn ein Benutzer dem Builder die Konfigurationsoption „preserveNestedDefaults“ bereitstellt, kann er die Schlüssel-Wert-Paare innerhalb eines verschachtelten Objekts oder Arrays beibehalten! Dies löst das Problem, dass ein Benutzer einen Schlüssel überschreibt, der kein primitiver Typ wie eine Zeichenfolge ist, sondern ein komplexerer Typ ist und alle Werte behält, mit Ausnahme derjenigen, die wir überschreiben möchten.

Das war schon eine ziemliche Lektüre, also lassen Sie uns mit dem Ergebnis all unserer harten Arbeit schließen. Schauen wir uns diesen ersten Mock noch einmal an und wie wir ihn mit zodObjectBuilder schreiben könnten. Definieren wir zunächst unsere Typen und Standardwerte und übergeben wir das resultierende Schema an 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

Die obige Implementierung gibt ein einzelnes Objekt mit allen Standardwerten zurück! Aber wir können es noch besser machen: Wir können jetzt (mit Hilfe einiger Überladungsdefinitionen und interner Analyse) Arrays von Objekten erstellen, perfekt für den Anwendungsfall, API-Antworten zu verspotten:

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

Die obige Ausgabe zeigt eine Reihe von Bestellungen mit den vollständigen Standardwerten und überschriebenen Lieferstatus! Hoffentlich zeigt dies, wie die zodObjectBuilder-Funktion den Aufwand minimieren kann, der zum Erstellen eines neuen Modells auf der Grundlage eines zuverlässigen typsicheren Schemas erforderlich ist.

Mit dieser kleinen Demonstration sind wir am Ende meines ersten Artikels angelangt :) Ich hoffe, dass Ihnen die Lektüre dieser Erkundungsreise zur Verbesserung des Spottens Spaß gemacht hat. zodObjectBuilder befindet sich noch in der Entwicklung, aber es erfüllt meine Anforderungen gut, um verspottete Objekte zu minimieren. Wenn Sie mit der aktuellen Version herumspielen möchten, finden Sie sie unter https://www.npmjs.com/package/@crbroughton/ts-utils, die die Funktion enthält.

Das obige ist der detaillierte Inhalt vonWie ich versucht habe, das Spotten mit Zod zu verbessern. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!