JavaScript Optional Chaining (?.): Safe Access to Nested Properties

The Problem: Nested Access Is Fragile

Reaching into a nested object is fine — right up until one of the levels isn't there:

user.address is undefined, and reading .city off undefined throws TypeError: Cannot read properties of undefined. Real-world data — API responses, parsed JSON, DOM queries — is full of fields that might or might not exist, and writing defensive checks for each level gets noisy fast:

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

Readable-ish with two levels. Painful at four. The ?. operator is the cleaner fix.

?. Short-Circuits on null and undefined

Optional chaining reads a property only if the value before it isn't null or undefined. If it is, the whole expression evaluates to undefined and stops.

Line one reads name normally. Line two hits user.address, sees undefined, and bails out — the rest of the chain never runs. Line three would throw without ?. because .toUpperCase() would be called on undefined; with ?., the whole thing quietly evaluates to undefined.

The mental model: ?. means "if what's before me is null or undefined, give up and return undefined — otherwise keep going."

It Works on Arrays and Function Calls Too

Three syntaxes, same idea:

• ?.[...] for array or dynamic property access.
• ?.() for calling something that may or may not be a function.
• ?.name for regular property access.

All three short-circuit the same way. user?.notAMethod?.() doesn't throw even though notAMethod doesn't exist — the second ?. sees undefined and stops.

This is especially handy for optional callbacks:

No more if (typeof onDone === "function") guards before every invocation.

Only null and undefined Trigger the Short-Circuit

This is the detail that trips people up. ?. only cares about nullish values. Other falsy values — 0, "", false, NaN — are perfectly valid objects to chain on (well, to the extent that autoboxing lets you):

data.count is 0, which is falsy but not nullish, so ?.toFixed(2) runs on it and returns "0.00". Contrast that with &&:

The && version returns 0 because data.count is falsy and short-circuits. The ?. version returns "0.00" because 0 isn't nullish. If you actually want to stop on 0, && is right. If you only want to stop on "the value is missing," ?. is what you want.

Where the ? Goes Matters

?. protects the value before it — not after. So place it on the level that might be missing:

All three work here because nothing's actually missing. But if config.server could be undefined, you need config.server?.host — a ?. before server wouldn't help, because the problem is reading .host off a missing server.

A good rule: put ?. on each level where the value to its left might genuinely be nullish. Scattering ?. on every dot "just in case" hides bugs and makes the code noisier.

Assigning Through ?. Doesn't Work

Optional chaining is read-only. You can't use it on the left of an assignment:

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

That makes sense if you think about it — what would it mean to assign to a property of undefined? If you need to set a value only when the parent exists, write it out:

When to Reach for It — and When Not To

?. shines when a value is legitimately optional:

• API responses where fields may or may not be included.
• DOM lookups: document.querySelector(".banner")?.remove().
• Callbacks that might not be passed: options.onError?.(err).
• Chained library calls where intermediate results can be null.

It's the wrong tool when the value should always exist. Sprinkling ?. to silence errors in that case converts a loud, findable bug ("TypeError on line 42") into a silent one (a variable mysteriously undefined three functions away). When something must be there, let it throw — the stack trace is doing you a favor.

A Realistic Example

Pulling a value out of a possibly-partial API response:

Each ?. handles one level of uncertainty. avatarUrl ends up undefined cleanly. onClick?.() calls the handler if it happens to be there.

You'll notice the ?? on the displayName line — that's the other half of this pattern. ?. gives you undefined when something's missing; ?? lets you substitute a default without tripping on legitimate falsy values like 0 or "".

Next: Nullish Coalescing

?. and ?? are the same idea applied to different problems: both treat null and undefined as "missing" and leave other falsy values alone. Next up, how ?? gives you sane default values — and why || has been quietly getting that wrong for years.