TypeScript interfészek generálása JSON-ból _

Hogyan működik a JSON → TypeScript következtetés

A következtetés egyetlen menet a feldolgozott JSON fán. Az eszköz beolvassa az egyes értékeket, kiválaszt egy TypeScript típust, majd kiír egy interfészt minden talált objektumhoz.

1. A JSON minta elemzése a böngésző natív elemzőjével, és a hibás bemenet elutasítása sor/oszlop segédlettel.
2. TypeScript típus érzékelése minden értékhez — string, number, boolean, null, tömb vagy beágyazott objektum.
3. Minden beágyazott objektumnak interfész nevet adni, amely a szülő tulajdonság kulcsából származik (így a user.address egy Address interfész lesz).
4. Elemtípusok összefésülése az egyes tömbökön belül, így a {id: 1} és {id: 2, label: "x"} listája egy uniót hoz létre a megfelelő opcionális mezőkkel.
5. Az Ön opcióinak alkalmazása (interface vs. type, readonly, opcionális-nullable) és deklarációk kibocsátása függőségi sorrendben, hogy a fájl előre mutogató hivatkozások nélkül forduljon.

Miért generáljunk TypeScript típusokat JSON-ból?

• A legtöbb alakzathiba elkapható fordítási időben, ha a válasz típus le van írva. Egy interfész következtetése egy valós adattartalomból a legtöbbet megírja Ön helyett, és a strict mód elkapja azt a mezőt, amelyet a dokumentáció elfelejtett említeni.
• A kikövetkeztetett interfészek párosítása egy futásidejű érvényesítővel, mint a Zod vagy az io-ts, ugyanannak az alakzatnak két feladatot ad: szerkesztői automatikus kiegészítés fejlesztés közben és egy 400-as válasz a peremnél, amikor a termelés valami váratlant küld.
• A TypeScript nyelvi szervere csak azokat a mezőket jeleníti meg, amelyekről tud. Miután importálta a kikövetkeztetett interfészt, az automatikus kiegészítés abban a pillanatban működik, amikor beírja a pontot — nincs több as any cast a válaszon és frusztrált grep a repón keresztül.
• Ha egy OpenAPI specifikációt fog írni, egy kikövetkeztetett interfész gyors első vázlat a válasz sémájához. Továbbra is kézzel írt példákra és megkötésekre lesz szüksége, de a tulajdonságnevek és típusok már helyesek.

Gyakori alkalmazások

A következtetés akkor segít a legtöbbet, amikor egy valós adattartalom létezik, de séma nem.

• Harmadik féltől származó webhook adattartalmak típusozása a Stripe-tól, GitHub-tól vagy Twilio-tól a kezelő írása előtt.
• Típusok előállítása egy belső REST API-hoz, hogy a frontend csapat még aznap elkezdhessen kódolni ellene, amikor a backend elkészül.
• Kiindulási pont generálása egy Zod, io-ts vagy Valibot sémához egy megfigyelt API-válaszból.

Hogyan néz ki a kimenet?

Adott egy minta JSON dokumentum és egy gyökér név, a generátor interfészek fáját hozza létre, egyet minden beágyazott objektumhoz. Az alábbi bemenethez a User gyökér névvel:

Illessze be a {"id":1,"name":"Alice","tags":["a","b"],"address":{"city":"Paris"}}-ot a User gyökér névvel, és a generátor a következőt hozza létre:

export interface User {
  id: number;
  name: string;
  tags: string[];
  address: Address;
}

export interface Address {
  city: string;
}

Generátor opciók

Deklarációs stílus

Válassza az interface-t (a szabványos TypeScript idióma objektum alakzatokhoz) vagy a type-ot (hasznos, ha később leképezett típusokra, feltételes típusokra vagy metszetekre lesz szüksége). Mindkettő azonos futásidejű viselkedést produkál; a választás kódolási stílus preferencia.

Opcionális null-álható mezők

Amikor egy mintavett érték null, a mező típusa T | null lesz. Az opció bekapcsolása ? módosítót is hozzáad, így a mező opcionális a TypeScript oldalon — hasznos, ha az API néha teljesen kihagyja a kulcsot ahelyett, hogy null-t adna vissza.

Readonly módosító

readonly-t fűz minden tulajdonság deklaráció elé, így a kiadott interfész egy megváltoztathatatlan adatmodellt tükröz. Praktikus Redux állapot szeletekhez, fagyasztott API válaszokhoz vagy bárhol, ahol azt szeretné, hogy a fordító jelezze a véletlen mutációt.

Támogatja ez a beágyazott objektumokat és tömböket?

Igen. Minden beágyazott objektum egy elnevezett interfésszé válik, amely a szülő tulajdonság kulcsából származik, és a tömbök kikövetkeztetik az elem típust a tartalmukból. Az objektumok tömbjei objektum alakzatonként egy interfészt kapnak, unió típusokkal, ahol az alakzatok eltérnek.

Hogyan következtetődnek ki az opcionális mezők?

Kapcsolja be a „Null-álható mezők opcionális jelölése” kapcsolót, és minden olyan mező, amelynek mintája null, ? módosítót kap a kulcson plusz | null a típusban. A kapcsoló nélkül a mező kötelező marad, és a típus csak T | null.

Támogatja ez a diszkriminált uniókat?

Az alapvető unió típusok akkor jönnek létre, amikor egy tömb vegyes alakzatú elemeket tartalmaz, vagy amikor egy mező értéket és null-t is hordoz. A teljes diszkriminált unió következtetés (a type vagy kind kiválasztása tag-ként és a változatok szétválasztása) több mintát igényel — ez tervezett, de nincs a mai build-ben.

Tudok típusokat következtetni több JSON mintából?

Még nem — a mai következtető egyszerre egy mintát olvas. Ha két olyan adattartalma van, amelyeknek meg kell osztaniuk egy interfészt (mondjuk egy lista végpont és egy egyelemű végpont), a gyakorlati megoldás az, hogy összefésüli őket egy tömbbe, abból generál, majd átnevezi a kapott unió típusokat. A több mintás következtetés az ütemterven van, mert ez az egyetlen módja annak, hogy észrevegye azokat a mezőket, amelyek az egyik válaszban jelen vannak, a másikból pedig hiányoznak.

Illesszen be egy adattartalmat, nevezze el a gyökeret, másolja az interfészeket. A teljes folyamat a böngészőjében fut, így egy kiadatlan API vagy egy aláírt webhook törzs az Ön gépén marad.