Tutti pensavano che TypeScript fosse solo un altro strato di noia aziendale – il trucco di Microsoft per incatenare gli sviluppatori a codice più verboso, vero? Sapete, roba che i VC pompano mentre i coder veri digrignano i denti con optional e any-type. Ma questi trucchi TypeScript che tiro fuori ogni giorno? Ribaltano tutto. Di botto, non stai più lottando con i tipi; sono loro a fare il lavoro sporco, tenendo i bug a distanza senza trasformare la tua codebase in un mattone.
Ho inseguito le lucciole della Silicon Valley per vent’anni – dalla bolla dei Java applet ai sogni febbricitanti dell’AI di oggi. E TypeScript? Non è una rivoluzione. È evoluzione. Evoluzione silenziosa e pragmatica che pone la domanda vera: chi sta spedendo codice più in fretta qui?
“Scrivo TypeScript da qualche anno su React Native, Node.js e un sacco di prodotti diversi. E c’è un abisso tra quello che ti insegnano i documenti e quello che finisci per usare ogni giorno.”
Rende l’idea alla perfezione. La doc rifila le basi. La realtà esige questi.
Discriminated Unions: Basta con la danza del Maybe-Undefined
Guardate.
Gestione dello stato nelle app – fetch di utenti, post, quel che vi pare – significava cospargere data?.foo?.bar ovunque. Snervante. Pericoloso.
Le discriminated unions risolvono tutto di netto. Etichetti ogni stato con un status letterale, e zac – TypeScript restringe i tipi come un laser. Ecco quello che copio-incollo in ogni progetto:
type RequestState =
| { status: "idle" }
| { status: "loading" }
| { status: "success"; data: User }
| { status: "error"; message: string };
Ora, nel tuo switch o if: if (state.status === 'success') { state.data.name } – niente controlli undefined. IntelliSense si accende. I bug svaniscono.
Non è roba nuova – i tipi Rust ci hanno preso in giro per anni senza questo. Ma nel mondo TypeScript? Fine dei runtime error per metà dei casi. E sì, i fan di React Query e Zustand ci giurano sopra.
Ma ecco il mio cinismo: Microsoft non l’ha inventato; l’ha solo reso comodo abbastanza perché pigri come me lo adottino. Chi vince? Quelli con meno issue su GitHub.
Perché ‘satisfies’ batte le annotazioni dirette tutte le volte
Il nuovo arrivato. satisfies. Sottile. Potente.
Vecchio modo: const config: Record<string, string> = { theme: 'dark', language: 'en' };. Va bene, ma addio inferenza di 'dark' o 'en' dopo. TypeScript allarga a string. Snervante quando chaini.
Ecco satisfies:
const config = {
theme: "dark",
language: "en",
} satisfies Record<string, string>;
I tipi controllati. Literal preservati. Magia.
Lo uso per config, mock, persino dati di test. Chain? config.theme === 'dark' ? darkMode() : lightMode(); – autocomplete completo. Niente sorprese ‘è solo stringa’.
Il mio scetticismo: perché non dal giorno uno? TypeScript 4.9 l’ha sfornato nel 2022, eppure metà tutorial lo ignora. Classico – gli strumenti arrancano dietro ai practitioner.
Utility Types: Pick, Omit e incatenale da pro
Partial e Required? Roba da bambini.
Lavoro vero: Pick, Omit, combo annidate.
// Taglia solo quello che serve per le anteprime
type Preview = Pick<Article, "title" | "slug" | "createdAt">;
// Togli i segreti per le API
type PublicUser = Omit<User, "password" | "token">;
// Update? Partial solo su specifici
type UpdateInput = Partial<Pick<User, "name" | "bio"> & { email?: string }>;
PublicUser passa codice client senza esporre hash. Preview nutre liste senza gonfiore. UpdateInput? Valida solo cosa cambia – niente sprawl di User interi su PATCH.
Incatenarle? È l’arte oscura. Sembra hacky all’inizio, ma dopo cinque anni è memoria muscolare. Risparmia ore di refactor API.
E l’angolo soldi – alle enterprise piace da matti. Bundle più magri, payload più sicuri. Le bollette Azure calano. Satya Nadella dorme s
