Optional chaining in JavaScript (?.): accesso sicuro

Il problema: l'accesso annidato è fragile

Entrare in un oggetto annidato va benissimo, finché uno dei livelli non c'è:

const user = { name: "Rosa" };

console.log(user.address.city);

user.address è undefined, e leggere .city da undefined lancia TypeError: Cannot read properties of undefined. I dati reali (risposte API, JSON analizzato, query sul DOM) sono pieni di campi che potrebbero esistere oppure no, e scrivere controlli difensivi per ogni livello diventa presto rumoroso:

const city = user && user.address && user.address.city;

Quasi leggibile con due livelli. Doloroso con quattro. L'operatore ?. è la soluzione più pulita.

?. va in cortocircuito su null e undefined

L'optional chaining legge una proprietà solo se il valore che la precede non è null o undefined. Se lo è, l'intera espressione vale undefined e si ferma.

const user = { name: "Rosa" };

console.log(user?.name);
console.log(user?.address?.city);
console.log(user?.address?.city?.toUpperCase());

La prima riga legge name normalmente. La seconda arriva a user.address, trova undefined e si arrende: il resto della catena non viene mai eseguito. La terza lancerebbe un errore senza ?., perché .toUpperCase() verrebbe chiamato su undefined; con ?. tutto vale semplicemente undefined, senza rumore.

Il modello mentale: ?. significa "se ciò che mi precede è null o undefined, lascia perdere e restituisci undefined, altrimenti vai avanti."

Funziona anche con array e chiamate di funzione

Tre sintassi, stessa idea:

const user = {
    name: "Boris",
    tags: ["admin", "editor"],
    greet() {
        return `hi, ${this.name}`;
    },
};

console.log(user?.tags?.[0]);
console.log(user?.greet?.());
console.log(user?.missing?.[0]);
console.log(user?.notAMethod?.());

• ?.[...] per accedere ad array o a proprietà dinamiche.
• ?.() per chiamare qualcosa che potrebbe essere una funzione oppure no.
• ?.name per il normale accesso alle proprietà.

Tutte e tre vanno in cortocircuito allo stesso modo. user?.notAMethod?.() non lancia errori anche se notAMethod non esiste: il secondo ?. vede undefined e si ferma.

È particolarmente comodo con le callback opzionali:

function fetchData(url, onDone) {
    const result = { url, status: 200 };
    onDone?.(result);
    return result;
}

fetchData("/users");
fetchData("/users", (r) => console.log("ricevuto:", r.status));

Niente più controlli if (typeof onDone === "function") prima di ogni chiamata.

Solo null e undefined attivano il cortocircuito

Questo è il dettaglio che sorprende molti. A ?. interessano solo i valori nullish. Gli altri valori falsy, cioè 0, "", false, NaN, sono oggetti perfettamente validi su cui concatenare (almeno nella misura in cui l'autoboxing lo consente):

const data = { count: 0, label: "" };

console.log(data?.count);
console.log(data?.label);
console.log(data?.count?.toFixed(2));

data.count è 0, che è falsy ma non nullish, quindi ?.toFixed(2) viene eseguito e restituisce "0.00". Confrontalo con &&:

const data = { count: 0 };

console.log(data && data.count && data.count.toFixed(2));
console.log(data?.count?.toFixed(2));

La versione con && restituisce 0 perché data.count è falsy e interrompe la valutazione. La versione con ?. restituisce "0.00" perché 0 non è nullish. Se vuoi davvero fermarti su 0, && è la scelta giusta. Se vuoi fermarti solo quando "il valore manca", ti serve ?..

Conta dove metti il ?

?. protegge il valore che viene prima, non quello dopo. Quindi mettilo sul livello che potrebbe mancare:

const config = { server: { host: "localhost" } };

console.log(config?.server.host);
console.log(config.server?.host);
console.log(config?.server?.host);

Qui funzionano tutte e tre perché in realtà non manca niente. Ma se config.server potesse essere undefined, ti servirebbe config.server?.host: un ?. prima di server non aiuterebbe, perché il problema è leggere .host da un server che non c'è.

Una buona regola: metti ?. su ogni livello in cui il valore prima di esso potrebbe essere davvero nullish. Spargere ?. su ogni punto "per sicurezza" nasconde i bug e rende il codice più rumoroso.

Assegnare tramite ?. non funziona

L'optional chaining è solo in lettura. Non puoi usarlo come destinazione di un'assegnazione:

user?.address?.city = "Paris";   // SyntaxError

Ha senso, se ci pensi: cosa vorrebbe dire assegnare a una proprietà di undefined? Se devi impostare un valore solo quando esiste l'oggetto genitore, scrivilo per esteso:

const user = { name: "Rosa", address: {} };

if (user?.address) {
    user.address.city = "Paris";
}

console.log(user);

Quando usarlo, e quando no

?. dà il meglio quando un valore è legittimamente opzionale:

• Risposte API in cui alcuni campi possono esserci oppure no.
• Ricerche nel DOM: document.querySelector(".banner")?.remove().
• Callback che potrebbero non essere passate: options.onError?.(err).
• Chiamate a librerie concatenate in cui i risultati intermedi possono essere null.

È lo strumento sbagliato quando il valore dovrebbe esistere sempre. Spargere ?. per zittire gli errori in quel caso trasforma un bug rumoroso e facile da trovare ("TypeError alla riga 42") in uno silenzioso (una variabile misteriosamente undefined tre funzioni più in là). Quando qualcosa deve esserci, lascia che lanci l'errore: lo stack trace ti sta facendo un favore.

Un esempio realistico

Estrarre un valore da una risposta API potenzialmente incompleta:

const response = {
    user: {
        name: "Ada",
        profile: {
            avatar: null,
        },
    },
};

const avatarUrl = response?.user?.profile?.avatar?.url;
const displayName = response?.user?.name ?? "Guest";
const onClick = response?.user?.profile?.onClick;

console.log(avatarUrl);
console.log(displayName);
onClick?.();

Ogni ?. gestisce un livello di incertezza. avatarUrl finisce per valere undefined in modo pulito. onClick?.() chiama l'handler se per caso c'è.

Avrai notato il ?? nella riga di displayName: è l'altra metà di questo pattern. ?. ti dà undefined quando qualcosa manca; ?? ti permette di sostituirlo con un default senza inciampare su valori falsy legittimi come 0 o "".

Prossimo passo: nullish coalescing

?. e ?? sono la stessa idea applicata a problemi diversi: entrambi trattano null e undefined come "mancante" e lasciano stare gli altri valori falsy. Nella prossima pagina vediamo come ?? ti dà valori di default sensati, e perché || da anni sbaglia in silenzio proprio su questo.