TypeScript Utility Types – Guida completa dal principiante all'avanzato (con Zod)

I TypeScript Utility Types sono tipi generici predefiniti che facilitano le trasformazioni di tipo. Permettono di creare nuovi tipi a partire da quelli esistenti, ad esempio rendendo alcune proprietà opzionali o estraendo il tipo di ritorno di una funzione. Questa guida educativa, in tre livelli (principiante, intermedio, avanzato), presenta tutti i principali Utility Types di TypeScript (come Partial, Required, Readonly, Pick, Omit, Record, Exclude, Extract, NonNullable, Parameters, ReturnType, InstanceType, ThisType, ecc.), con per ciascuno: una spiegazione della sua utilità, un esempio d'uso in TypeScript, quindi un confronto con un approccio equivalente in Zod, una libreria di validazione a runtime. Discuteremo anche le differenze filosofiche tra gli Utility Types di TypeScript (sistema di tipi statico) e gli schemi Zod (validazione a runtime).

Configurazione del progetto con Bun

Per provare gli esempi di codice, puoi inizializzare un progetto TypeScript minimale usando Bun (un runner JavaScript ultra-veloce che funge anche da gestore di pacchetti). Assicurati di avere Bun installato, poi in una cartella vuota esegui:

shell

Bun creerà un package.json e un tsconfig.json di default. Puoi poi eseguire un file TypeScript con bun run file.ts (Bun transpila TypeScript al volo).

Siamo pronti per esplorare gli Utility Types!

Livello principiante: utility di base del sistema di tipi

Partial<T> – Proprietà opzionali

TypeScript: Il tipo utility Partial<T> costruisce un tipo a partire da un tipo esistente T rendendo tutte le sue proprietà opzionali. In altre parole, ogni proprietà di T diventa opzionale (aggiungendo ?). Questo ti permette di rappresentare oggetti parziali di questo tipo. Ad esempio, se hai un tipo User con campi obbligatori, Partial<User> ti permette di creare una versione in cui questi campi possono essere omessi:

typescript

Qui, Partial<User> ha il tipo { name?: string; age?: number }. Questo ti permette, ad esempio, di implementare una funzione di aggiornamento parziale senza richiedere tutti i campi:

typescript

Puoi chiamare updateUser(existingUser, { age: 26 }) con un oggetto parziale – TypeScript garantisce staticamente che fieldsToUpdate contenga solo chiavi valide di User.

Equivalente con Zod: Zod offre un metodo equivalente per rendere uno schema oggetto parziale. Il metodo .partial() applicato a uno schema z.object rende tutte le chiavi opzionali, simile a Partial in TypeScript. Ad esempio:

typescript

Qui PartialUserSchema è uno schema che valida oggetti che possono contenere solo un sottoinsieme di chiavi (name e age diventano opzionali). Puoi verificarlo così:

typescript

Zod permette anche di rendere opzionali solo alcune proprietà passando un oggetto come parametro (UserSchema.partial({ age: true }) rende opzionale solo age). Nota che .partial() agisce solo sul primo livello; Zod offre anche .deepPartial() per rendere opzionali ricorsivamente i campi annidati.

Required<T> – Proprietà obbligatorie

TypeScript: Il tipo utility Required<T> è l'opposto di Partial: crea un tipo a partire da T rendendo tutte le sue proprietà obbligatorie (non opzionali). È utile per "solidificare" un tipo le cui proprietà erano opzionali. Ad esempio:

typescript

In questo esempio, Required<Settings> è equivalente a { theme: string; fontSize: number } – l'omissione di una proprietà diventa un errore di compilazione.

Equivalente con Zod: Per uno schema Zod, l'equivalente è il metodo .required(), che trasforma uno schema oggetto rendendo tutte le proprietà obbligatorie (a differenza di .partial() che le rende opzionali). Questo metodo è particolarmente utile se prima hai definito uno schema parziale e vuoi ottenere la versione stretta. Ad esempio:

typescript

Qui StrictUserSchema richiede che name e age siano presenti. Puoi anche specificare solo alcune proprietà: BaseUserSchema.required({ age: true }) rende obbligatorio solo age (e lascia name opzionale).

Nota che Required<T> agisce a compile time (non esiste più nel codice JavaScript emesso), mentre schema.required() di Zod agisce a runtime validando la presenza delle chiavi durante il parsing.

Readonly<T> – Proprietà immutabili

TypeScript: Il tipo utility Readonly<T> trasforma un tipo T rendendo le sue proprietà di sola lettura (immutabili). Qualsiasi tentativo di riassegnare queste proprietà sarà segnalato come errore in compilazione. Ad esempio:

typescript

Qui, todo è di tipo Readonly<Todo> quindi i suoi campi non possono essere modificati dopo l'inizializzazione. Questo spesso corrisponde all'uso di Object.freeze in JavaScript, ma TypeScript lo gestisce solo a livello di tipo (non impedisce realmente la mutazione a runtime, avvisa solo a compile time).

Equivalente con Zod: Zod offre una funzionalità interessante per l'immutabilità. Il metodo .readonly() applicato a uno schema restituisce un nuovo schema che, durante il parsing, chiama Object.freeze() sul risultato, e il cui tipo statico è contrassegnato come Readonly<...>. In altre parole, Zod può congelare l'oggetto validato e garantire che corrisponda a un tipo readonly. Ad esempio:

typescript

Qui, FrozenUserSchema congela l'oggetto restituito da parse. Se provi a modificare frozenUser, verrà lanciata un'eccezione a runtime perché l'oggetto è immutabile. Quindi, Zod va oltre TypeScript: dove Readonly<T> è puramente statico (le proprietà potrebbero essere modificate in JS se si aggira il typing), lo schema .readonly() di Zod garantisce una reale immutabilità a runtime oltre a fornire il corrispondente tipo Readonly<...>.

Pick<T, Keys> – Selezione di un sottoinsieme di proprietà

TypeScript: Pick<T, Keys> costruisce un nuovo tipo da T mantenendo solo alcune proprietà specificate da Keys (tipicamente una union di string literal che rappresentano i nomi delle proprietà). È utile per creare un tipo più ristretto da uno esistente. Ad esempio:

typescript

Qui, TodoPreview mantiene solo title e completed da FullTodo. Qualsiasi proprietà non elencata (ad esempio description) è esclusa dal tipo risultante.

Equivalente con Zod: Gli schemi oggetto di Zod hanno anche un metodo .pick() che crea un nuovo schema contenente solo le chiavi indicate, in modo simile:

typescript

Passi un oggetto con le chiavi da mantenere impostate su true. TodoPreviewSchema validerà solo oggetti con title e completed (le altre proprietà di FullTodo saranno ignorate dal parser di default). Ad esempio, TodoPreviewSchema.parse({ title: "Clean", completed: false, description: "..." }) restituirà { title: "...", completed: false } avendo rimosso description (perché di default Zod ignora le chiavi non specificate, comportamento che può essere regolato con .strict() o .passthrough() se necessario).

Allo stesso modo, Zod fornisce .omit() per l'effetto opposto.

Omit<T, Keys> – Esclusione di proprietà

TypeScript: Omit<T, Keys> crea un nuovo tipo a partire da T rimuovendo alcune proprietà (Keys). È il complemento di Pick (in effetti Omit<T, K> è spesso implementato come Pick<T, Exclude<keyof T, K>>). Esempio:

typescript

Qui TaskMeta contiene solo id e title. Le proprietà done e dueDate sono state escluse.

Equivalente con Zod: Il metodo .omit() di Zod produce uno schema oggetto senza le chiavi indicate. Esempio:

typescript

TaskMetaSchema validerà oggetti contenenti solo id e title. Qualsiasi chiave omessa (done, dueDate) sarà ignorata se presente nell'input. Pick e Omit ti permettono di proiettare uno schema Zod su un sottoinsieme di campi proprio come i loro equivalenti TypeScript a livello di tipo.

Record<Keys, Type> – Dizionario di chiavi tipizzate

TypeScript: Record<Keys, Type> costruisce un tipo oggetto le cui chiavi sono di tipo Keys (tipicamente una union di string literal o un tipo string/number più generale) e i valori sono di tipo Type. Questo ti permette di descrivere, ad esempio, un oggetto indicizzato da identificatori. Un classico esempio:

typescript

Qui, Record<CatName, CatInfo> assicura che l'oggetto cats abbia esattamente le chiavi "miffy", "boris", "mordred", ciascuna associata a un CatInfo. Record è molto utile per tipizzare oggetti usati come dizionari o mappe.

Equivalente con Zod: Zod offre lo schema z.record(keySchema, valueSchema) per validare oggetti di questo tipo. Puoi usarlo con uno schema chiave (ad esempio z.string() o uno schema literal) e uno schema valore. Esempio:

typescript

Qui, AgeMapSchema valida qualsiasi chiave purché sia una stringa (di default, z.record senza primo argomento assume string). Se hai un insieme finito di chiavi, spesso è meglio usare z.object({ ... }) con chiavi esplicite o z.enum([...]) per limitare le chiavi. In effetti, Zod permette uno schema chiave più restrittivo: puoi definire const CatNameSchema = z.enum(["miffy","boris","mordred"]) e poi fare z.record(CatNameSchema, CatInfoSchema) – tuttavia, a runtime le chiavi degli oggetti JavaScript sono sempre stringhe. Anche una chiave numerica sarà convertita in stringa a runtime (ad esempio, una chiave 1 diventa "1" in un oggetto JS). Zod tiene conto di questo e non permette di definire uno schema chiave puramente numerico senza trasformarlo in stringa.

In sintesi, Record<Keys, Type> (TypeScript) e z.record(keySchema, valueSchema) (Zod) ti permettono entrambi di tipizzare dizionari. Il primo agisce a livello di sistema di tipi, il secondo a runtime per validare la struttura dell'oggetto.

Livello intermedio: manipolazione di union e tipi opzionali

Exclude<UnionType, ExcludedMembers> – Rimozione di membri da una union

TypeScript: Exclude<U, E> crea un tipo rimuovendo dalla union U tutti i membri assegnabili al tipo E. In altre parole, escludi certi tipi da una union. Ad esempio:

typescript

Qui, Exclude<Role, "admin"> rimuove il literal "admin" dalla union, lasciando solo "user" | "guest". Un altro esempio: Exclude<string | number | boolean, string> darebbe number | boolean (rimuovendo tutto ciò che è assegnabile a string). È utile per affinare una union eliminando i casi indesiderati.

Equivalente con Zod: Per restringere le possibilità di una union a runtime, in genere definisci uno schema che non includa i casi da escludere. Ad esempio, se hai RoleSchema = z.enum(["admin","user","guest"]) puoi creare un sottoinsieme non includendo "admin". Zod fornisce per le enumerazioni il metodo .exclude([...]) che genera un nuovo schema enum senza i valori specificati. Ad esempio:

typescript

Questo NonAdminSchema corrisponde esattamente al tipo Exclude<Role, "admin"> ma garantisce anche la validazione a runtime. Internamente, RoleSchema.exclude(["admin"]) rimuove semplicemente "admin" dalla lista dei literal consentiti. Allo stesso modo, Zod offre .extract([...]) per l'operazione complementare.

Extract<Type, Union> – Estrazione di membri da una union

TypeScript: Extract<T, U> crea un tipo mantenendo da T solo i membri assegnabili a U. È grosso modo l'opposto di Exclude. Ad esempio:

typescript

Un altro esempio: Extract<"a" | "b" | "c", "a" | "f"> darà "a" (perché solo "a" è comune a entrambi). Questo tipo utility viene quindi usato per filtrare una union ed estrarre solo un certo sottotipo.

Equivalente con Zod: Come per Exclude, Zod permette di ottenere a runtime uno schema corrispondente a un sottoinsieme di un'enumerazione tramite .extract([...]). Prendiamo di nuovo l'esempio dei ruoli: per estrarre solo, ad esempio, i ruoli limitati "user" e "guest" da un RoleSchema completo:

typescript

Qui LimitedRolesSchema corrisponde al tipo Extract<Role, "user" | "guest">. In pratica, potresti ottenere lo stesso risultato definendo direttamente z.enum(["user","guest"]), ma .extract è comodo per derivare uno schema da un enum esistente. Nota che .exclude e .extract di Zod si applicano agli schemi enum (z.enum o z.nativeEnum), e non a union arbitrarie di tipi complessi. Per questi ultimi, in genere costruisci manualmente il nuovo schema union desiderato.

NonNullable<T> – Esclusione di null e undefined

TypeScript: NonNullable<T> costruisce un tipo escludendo null e undefined da T. È comune in TypeScript avere tipi union che includono questi valori "nullish" e voler un tipo che ne sia privo. Ad esempio:

typescript

Qui, DefinitelyString contiene solo string (né null né undefined). Questo tipo utility è spesso usato in combinazione con condizioni di presenza (if (value != null) { ... }) per aiutare il compilatore a raffinare i tipi.

Equivalente con Zod: Con Zod, di default gli schemi non accettano undefined o null a meno che tu non lo specifichi. Ad esempio, uno schema z.string() accetta solo una stringa, non undefined. Per permettere questi valori, usi esplicitamente z.string().optional() (che permette undefined) o z.string().nullable() (che permette null) o anche .nullish() (che permette entrambi). Quindi, ottenere l'equivalente di un tipo NonNullable significa semplicemente non includere null/undefined nello schema. Tuttavia, se parti da uno schema più permissivo e vuoi renderlo più restrittivo, puoi usare una combinazione di tecniche: ad esempio, il metodo .unwrap() permette di estrarre lo schema sottostante da uno schema opzionale o nullable.

typescript

Qui, OptionalName.unwrap() restituisce lo schema z.string() originale. Questo ti permette di "rimuovere" il carattere opzionale o nullable introdotto in precedenza. Un altro approccio sarebbe usare una validazione personalizzata per rifiutare null/undefined, ma sarebbe ridondante dato il comportamento degli schemi Zod.

Livello avanzato: tipi funzione e classi

Parameters<Type> – Tipi dei parametri di funzione

TypeScript: Parameters<T> estrae i tipi dei parametri di un tipo funzione T come tupla. È utile per lavorare con le firme delle funzioni, specialmente quando vuoi creare una funzione che avvolge un'altra funzione. Ad esempio:

typescript

Qui, Parameters<typeof greet> estrae la tupla [string, number] che rappresenta i parametri di greet. Questo permette a safeGreet di accettare esattamente gli stessi parametri di greet.

Equivalente con Zod: Zod fornisce z.function() per definire schemi di funzione, con metodi per specificare i tipi dei parametri e il tipo di ritorno. Anche se non c'è un equivalente diretto di Parameters<T>, puoi definire uno schema funzione ed estrarre i tipi dei parametri usando Parameters di TypeScript sul tipo inferito:

typescript

Qui, GreetSchema definisce uno schema funzione che accetta una stringa e un numero e restituisce una stringa. Il metodo .implement() crea una funzione wrapper che valida input e output secondo lo schema. Possiamo estrarre i tipi dei parametri usando Parameters<GreetFn>. Questo approccio combina validazione a runtime con tipizzazione statica.

ReturnType<Type> – Tipo di ritorno di una funzione

TypeScript: ReturnType<T> estrae il tipo di ritorno di un tipo funzione T. È utile quando vuoi lavorare con il risultato di una funzione senza dover ridefinire esplicitamente il tipo. Ad esempio:

typescript

Qui, ReturnType<typeof createUser> estrae il tipo oggetto restituito da createUser. Questo ci permette di definire il tipo User senza duplicare la struttura.

Equivalente con Zod: Come per Parameters, non c'è un equivalente diretto in Zod per ReturnType, ma puoi combinare lo schema funzione di Zod con ReturnType di TypeScript:

typescript

Qui, definiamo uno schema funzione con CreateUserSchema, poi estraiamo il tipo di ritorno in due modi: usando ReturnType di TypeScript sul tipo funzione inferito, o usando il metodo .returnType() di Zod che restituisce lo schema per il valore di ritorno. Entrambi gli approcci ci danno il tipo User.

InstanceType<Type> – Tipo istanza di una classe

TypeScript: InstanceType<T> estrae il tipo istanza di un tipo costruttore T. È utile quando hai un riferimento a una classe e vuoi lavorare con le istanze di quella classe. Ad esempio:

typescript

Qui, InstanceType<typeof Point> ci dà il tipo di un'istanza Point, che include le sue proprietà e metodi.

Equivalente con Zod: Zod non ha un equivalente diretto per i tipi istanza di classe, poiché si concentra sulla validazione dei dati piuttosto che sul comportamento delle classi. Tuttavia, puoi definire uno schema per la forma delle istanze di classe:

typescript

Questo approccio definisce uno schema che corrisponde alla forma di un'istanza Point, ma non cattura la relazione completa della classe. Per una validazione di classe più complessa, potresti dover combinare Zod con class-validator o librerie simili.

Differenze filosofiche tra TypeScript Utility Types e Zod Schemas

I TypeScript Utility Types e gli schemi Zod servono entrambi a garantire l'affidabilità dei dati, ma a livelli diversi: uno a compile time, l'altro a runtime.

• TypeScript: sicurezza statica (compile-time) – Gli Utility Types (e il sistema di tipi in generale) operano durante lo sviluppo. TypeScript analizza il codice e previene incoerenze di tipo prima che il codice venga eseguito. Ad esempio, Partial<T> assicura che una funzione non dimentichi di gestire i casi in cui mancano proprietà, ReturnType<Fn> fornisce la forma attesa dei ritorni di funzione, ecc. Tuttavia, questi controlli non esistono più una volta che l'applicazione è in esecuzione: TypeScript elimina i tipi durante la transpilation in JavaScript. Nulla impedisce che dati errati circolino a runtime (provenienti da JSON, form utente, API esterne...). Il sistema di tipi da solo non può proteggere da valori inaspettati a runtime.
• Zod: validazione dinamica (runtime) – Gli schemi Zod intervengono a runtime per colmare questa lacuna. Definendo uno schema per i tuoi dati, crei una guardia a runtime che verifica che i dati ricevuti corrispondano al formato atteso. Ad esempio, uno PartialUserSchema verificherà effettivamente che l'oggetto ricevuto contenga solo chiavi valide e che i loro valori siano del tipo corretto, mentre Partial<T> è solo una garanzia a compile time. Quindi, Zod e TypeScript sono complementari: TypeScript assicura la coerenza interna del tuo codice (ciò che manipoli corrisponde ai tipi dichiarati), mentre Zod assicura che i dati esterni siano conformi ai tuoi tipi.

In sintesi:

• TypeScript è una guardia a compile time che intercetta gli errori precocemente nel ciclo di sviluppo e ti aiuta a evitare molti errori comuni prima ancora di eseguire il codice.
• Zod è una guardia a runtime che assicura che nessun dato non conforme "passi la porta" della tua applicazione (input utente, risposta API, contenuto di configurazione, ecc.).

Filosoficamente, gli utility types esprimono trasformazioni o vincoli a livello di sistema di tipi (aiutano lo sviluppatore, senza impatto diretto sul codice emesso), mentre Zod fornisce contratti a livello di runtime (permette l'implementazione concreta di validazioni e trasformazioni dei dati in esecuzione). Entrambi gli approcci rispondono a esigenze diverse ma correlate: mantenere la robustezza del codice. Inoltre, Zod è progettato per integrarsi armoniosamente con TypeScript: inferisce automaticamente i tipi statici dai tuoi schemi, evitando la duplicazione delle definizioni. Questo significa che spesso puoi definire uno schema Zod (per la validazione) e usare z.infer per derivare il corrispondente tipo statico TypeScript, invece di definire un'interfaccia TypeScript e uno schema separato – avendo così una sola fonte di verità per i tuoi tipi di dati.

In conclusione, conoscere i TypeScript Utility Types ti permette di sfruttare il sistema di tipi per scrivere codice sicuro ed espressivo, mentre padroneggiare Zod ti dà gli strumenti per far rispettare questi contratti di tipo a runtime. Usati insieme, rafforzano notevolmente l'affidabilità delle tue applicazioni TypeScript: TypeScript ti protegge dagli errori di programmazione, Zod protegge la tua applicazione da dati inaspettati provenienti dall'esterno. Crea i tuoi tipi, valida i tuoi dati e programma con serenità 🎉!

1bun init
2bun add zod             # aggiunge Zod come dipendenza

1interface User {
2  name: string;
3  age: number;
4}
5
6const partialUser: Partial<User> = { name: 'Alice' };
7// 'partialUser' può contenere solo il nome, la proprietà 'age' è opzionale
8partialUser.age = 30; // OK da aggiungere dopo perché age: number | undefined

1function updateUser(user: User, fieldsToUpdate: Partial<User>): User {
2  return { ...user, ...fieldsToUpdate };
3}

1import { z } from 'zod';
2
3const UserSchema = z.object({
4  name: z.string(),
5  age: z.number(),
6});
7const PartialUserSchema = UserSchema.partial();
8type PartialUser = z.infer<typeof PartialUserSchema>;
9// PartialUser è di tipo { name?: string; age?: number }

1PartialUserSchema.parse({ name: 'Alice' }); // OK (age mancante consentito)
2PartialUserSchema.parse({}); // OK (può essere vuoto)
3PartialUserSchema.parse({ age: ' thirty ' }); // Errore: age non è un numero

1interface Settings {
2  theme?: string;
3  fontSize?: number;
4}
5const s1: Settings = { theme: 'dark' }; // OK, fontSize mancante
6const s2: Required<Settings> = { theme: 'dark' }; // Errore – fontSize è obbligatorio
7// TypeScript: Property 'fontSize' is missing in type ... but required in type 'Required<Settings>'

1const BaseUserSchema = z.object({
2  name: z.string().optional(),
3  age: z.number().optional(),
4});
5// BaseUserSchema: { name?: string; age?: number }
6const StrictUserSchema = BaseUserSchema.required();
7// StrictUserSchema: { name: string; age: number }

1interface Todo {
2  title: string;
3  done: boolean;
4}
5const todo: Readonly<Todo> = { title: 'Init project', done: false };
6todo.done = true;
7// Errore TS: Cannot assign to 'done' because it is a read-only property.

1const FrozenUserSchema = z.object({ name: z.string() }).readonly();
2type FrozenUser = z.infer<typeof FrozenUserSchema>;
3// FrozenUser: Readonly<{ name: string }>
4const frozenUser = FrozenUserSchema.parse({ name: 'Bob' });
5frozenUser.name; // "Bob"
6frozenUser.name = 'Eve'; // Errore a runtime: l'oggetto è congelato (TypeError in strict mode)

1interface FullTodo {
2  title: string;
3  description: string;
4  completed: boolean;
5}
6type TodoPreview = Pick<FullTodo, 'title' | 'completed'>;
7// TodoPreview: { title: string; completed: boolean }
8const t: TodoPreview = { title: 'Clean', completed: false }; // OK

1const FullTodoSchema = z.object({
2  title: z.string(),
3  description: z.string(),
4  completed: z.boolean(),
5});
6const TodoPreviewSchema = FullTodoSchema.pick({ title: true, completed: true });
7type TodoPreview = z.infer<typeof TodoPreviewSchema>;
8// { title: string; completed: boolean }

1interface Task {
2  id: string;
3  title: string;
4  done: boolean;
5  dueDate: string;
6}
7type TaskMeta = Omit<Task, 'done' | 'dueDate'>;
8// TaskMeta: { id: string; title: string }

1const TaskSchema = z.object({
2  id: z.string(),
3  title: z.string(),
4  done: z.boolean(),
5  dueDate: z.string(),
6});
7const TaskMetaSchema = TaskSchema.omit({ done: true, dueDate: true });
8type TaskMeta = z.infer<typeof TaskMetaSchema>;
9// { id: string; title: string }

1type CatName = 'miffy' | 'boris' | 'mordred';
2interface CatInfo {
3  age: number;
4  breed: string;
5}
6type Cats = Record<CatName, CatInfo>;
7/* Equivalente a:
8type Cats = {
9  miffy: CatInfo;
10  boris: CatInfo;
11  mordred: CatInfo;
12}
13*/
14const cats: Cats = {
15  miffy: { age: 10, breed: 'Persiano' },
16  boris: { age: 5, breed: 'Maine Coon' },
17  mordred: { age: 16, breed: 'British Shorthair' },
18};

1// Vogliamo un oggetto le cui chiavi sono nomi (string) e i valori sono età (number)
2const AgeMapSchema = z.record(z.string(), z.number());
3type AgeMap = z.infer<typeof AgeMapSchema>;
4// AgeMap: Record<string, number>
5AgeMapSchema.parse({ Alice: 30, Bob: 25 }); // OK
6AgeMapSchema.parse({ Alice: 30, Bob: '25' }); // Errore: "25" non è un numero

1type Role = 'admin' | 'user' | 'guest';
2type NonAdmin = Exclude<Role, 'admin'>;
3// NonAdmin: "user" | "guest"

1const RoleSchema = z.enum(['admin', 'user', 'guest']);
2const NonAdminSchema = RoleSchema.exclude(['admin']);
3type NonAdmin = z.infer<typeof NonAdminSchema>;
4// NonAdmin: "user" | "guest"
5NonAdminSchema.parse('user'); // OK
6NonAdminSchema.parse('admin'); // Errore: "admin" è escluso

1type Mixed = string | number | boolean;
2type NumbersOnly = Extract<Mixed, number | boolean>;
3// NumbersOnly: number | boolean (manteniamo solo ciò che è assegnabile a number | boolean)

1const LimitedRolesSchema = RoleSchema.extract(['user', 'guest']);
2type LimitedRoles = z.infer<typeof LimitedRolesSchema>;
3// LimitedRoles: "user" | "guest"
4LimitedRolesSchema.parse('guest'); // OK
5LimitedRolesSchema.parse('admin'); // Errore, "admin" non è estratto

1type MaybeString = string | null | undefined;
2type DefinitelyString = NonNullable<MaybeString>;
3// DefinitelyString: string

1const OptionalName = z.string().optional(); // tipo: string | undefined
2const Name = OptionalName.unwrap(); // recupera lo z.string() sottostante (tipo: string)
3Name.parse('Alice'); // "Alice"
4Name.parse(undefined); // Errore: undefined non accettato

1function greet(name: string, age: number): string {
2  return `Hello ${name}, you are ${age} years old`;
3}
4type GreetParams = Parameters<typeof greet>;
5// GreetParams: [name: string, age: number]
6
7// Possiamo usare questo tipo per creare una funzione che chiama greet
8function safeGreet(...args: GreetParams): string {
9  try {
10    return greet(...args);
11  } catch (e) {
12    return 'Greeting failed';
13  }
14}

1const GreetSchema = z
2  .function()
3  .args(z.string(), z.number())
4  .returns(z.string());
5
6type GreetFn = z.infer<typeof GreetSchema>; // tipo: (name: string, age: number) => string
7type GreetParams = Parameters<GreetFn>; // tipo: [string, number]
8
9// Possiamo usare questo schema per validare una funzione
10const greet = GreetSchema.implement((name, age) => {
11  return `Hello ${name}, you are ${age} years old`;
12});
13// greet è ora una funzione validata che lancerà un errore se chiamata con tipi errati

1function createUser(name: string) {
2  return { id: Date.now(), name, createdAt: new Date() };
3}
4type User = ReturnType<typeof createUser>;
5// User: { id: number; name: string; createdAt: Date }
6
7// Possiamo ora usare questo tipo altrove
8function processUser(user: User) {
9  console.log(`Processing user ${user.name} created at ${user.createdAt}`);
10}

1const CreateUserSchema = z
2  .function()
3  .args(z.string())
4  .returns(
5    z.object({
6      id: z.number(),
7      name: z.string(),
8      createdAt: z.date(),
9    }),
10  );
11
12type CreateUserFn = z.infer<typeof CreateUserSchema>;
13// tipo: (name: string) => { id: number; name: string; createdAt: Date }
14type User = ReturnType<CreateUserFn>;
15// tipo: { id: number; name: string; createdAt: Date }
16
17// Possiamo anche estrarre direttamente lo schema di ritorno
18const UserSchema = CreateUserSchema.returnType();
19// UserSchema è lo schema oggetto per il valore di ritorno
20type User2 = z.infer<typeof UserSchema>; // Uguale a User

1class Point {
2  x: number;
3  y: number;
4
5  constructor(x: number, y: number) {
6    this.x = x;
7    this.y = y;
8  }
9
10  distanceFromOrigin(): number {
11    return Math.sqrt(this.x * this.x + this.y * this.y);
12  }
13}
14
15type PointInstance = InstanceType<typeof Point>;
16// PointInstance: Point (il tipo istanza, con x, y e distanceFromOrigin)
17
18// Possiamo usare questo tipo senza avere un\'istanza reale
19function processPoint(p: PointInstance) {
20  console.log(
21    `Point at (${p.x}, ${p.y}) is ${p.distanceFromOrigin()} from origin`,
22  );
23}

1const PointSchema = z.object({
2  x: z.number(),
3  y: z.number(),
4  distanceFromOrigin: z.function().args().returns(z.number()),
5});
6
7type PointLike = z.infer<typeof PointSchema>;
8// tipo: { x: number; y: number; distanceFromOrigin: () => number }
9
10// Possiamo validare se un oggetto corrisponde all'interfaccia Point
11function isPoint(obj: unknown): obj is PointLike {
12  return PointSchema.safeParse(obj).success;
13}