Shorthand syntax and what it expands to

a?.b reads b from a — unless a is null or undefined, in which case the whole expression is undefined and nothing after it runs. It is shorthand for a check you would otherwise write by hand:

const city = user?.address?.city;

// expands to (roughly):
const sameCity =
  user === null || user === undefined ? undefined
  : user.address === null || user.address === undefined ? undefined
  : user.address.city;

There are three forms, one for each way of reaching into a value:

The third one is the one people miss in review: props.onChange?.(value) calls onChange only if it was passed, so an optional callback prop doesn't need an if.

Two things ?. does not do:

• It checks only for null and undefined. An empty string, 0 or false on the left is a real value, and the access goes ahead.
• It guards only the value directly to its left. user?.address.city protects you from a missing user, but throws if user exists and address doesn't.

It always produces undefined when it stops — never null, even if the value it stopped at was null.

A component's props, an API response and a function's options object are all unpacked the same way. One line that does five things:

function OrderRow({ order, currency = "USD", onSelect, ...rest }: OrderRowProps) { … }

const { data: orders = [], error } = await fetchOrders();

const { id: orderId, customer: { name } } = order;

const [first, , third = "n/a"] = lines;

Read each piece as the property access it replaces:

• { order } — const order = props.order.
• currency = "USD" — const currency = props.currency === undefined ? "USD" : props.currency. The default applies only when the value is undefined — missing, or explicitly undefined. A null is a value, and you get null.
• ...rest — a new object holding every own enumerable property that wasn't named (className, aria-*, …), ready to spread onto a DOM element. It must come last.
• data: orders = [] — rename and default: read data, call it orders, use [] if it's undefined. The colon in a pattern means "rename", not "type" — TypeScript annotations go after the whole pattern (}: OrderRowProps).
• customer: { name } — nested: read order.customer, then its name. This throws a TypeError if order.customer is undefined; there is no ?. inside a pattern. Give the middle level a default (customer: { name } = {}) if it can be missing.
• [first, , third = "n/a"] — arrays destructure by position; an empty slot skips one.

The null trap, side by side

APIs and databases often send null for "no value", and JSON.parse keeps it. Destructuring defaults won't catch it:

const response = JSON.parse('{"pageSize": null}');

const { pageSize = 20 } = response;
pageSize; // null — the default was skipped

const size = response.pageSize ?? 20;
size;     // 20 — ?? treats null and undefined alike

TypeScript models this exactly: for pageSize?: number | null, the destructured pageSize is typed number | null, so the compiler tells you the default didn't cover everything.

Function parameters follow the same rule. function paginate({ page = 1 } = {}) works when called with nothing or undefined, but paginate(null) throws: the = {} default only replaces undefined, and destructuring null is a TypeError.

The whole chain short-circuits

When ?. meets null or undefined, it skips everything to its right in the same chain — property reads, index expressions, calls, their side effects:

let i = 0;
const order = null;
const sku = order?.items[i++].sku;
sku; // undefined
i;   // 0 — items[i++] was never evaluated

There is no ?. after items, yet nothing threw: once order?. stopped, .items[i++].sku didn't run. The chain ends at a parenthesis, though: (order?.items).length evaluates (undefined).length and throws a TypeError.

What each form still lets through

• a?.b.c guards a only. If a exists and a.b is undefined, .c throws.
• fn?.() checks that fn isn't null/undefined — not that it is a function. With props.onChange set to a string, props.onChange?.() throws props.onChange is not a function. And it doesn't guard props itself: that needs props?.onChange?.().
• No optional assignment. user?.name = "Ada" is a SyntaxError. Assign inside an if.

?? refuses to mix

a || b ?? c and a && b ?? c are SyntaxErrors — the language won't guess the precedence you meant, and the whole module fails to load. Add parentheses: (a || b) ?? c.

?. vs && chains

Older code writes user && user.profile && user.profile.name. It is not the same thing: && stops at any falsy value and returns it, while ?. stops only at null/undefined and returns undefined. With user = null, the && chain gives null and user?.profile?.name gives undefined. And a falsy value that isn't nullish stops && but not ?.: with price = 0, price && price.toFixed(2) is 0, while price?.toFixed(2) is "0.00". That difference shows up when the result is rendered or compared with === undefined.

TypeScript's ! is not a runtime check

props.onSelect!(item) looks like a cousin of ?., but the ! (non-null assertion) is erased when TypeScript compiles — the emitted code is props.onSelect(item). It tells the compiler "trust me, this isn't null", and if you're wrong it crashes exactly as the plain call would. ?. checks at runtime; ! checks nothing.