This is a follow up question I asked incidentally at the end of Why does the TypeScript compiler compile its optional chaining and null-coalescing operators with two checks? As resident TypeScript legend jcalz pointed out in a comment, it does deserve its own question.
// Why does the JavaScript treat
x?.y
// as
x === null || x === void 0 ? void 0 : x.y
// instead of
x === null || x === void 0 ? x : x.y
// ?
When x == null, the latter would preserve null while the former always returns undefined.
Modern browsers support ?. natively, so we can test this behavior.
const test = () => {
console.log('undefined?.x\t\t==>\t', undefined?.x);
console.log('null?.x\t\t\t==>\t', null?.x);
console.log('null?.x === null\t==>\t', null?.x === null);
};
try {
eval('null?.x');
test();
} catch {
console.error('Your browser does not support optional chaining syntax.');
console.info('While optional chaining is supported by all modern browsers, this will not work in browsers that do not support the syntax.')
console.warn('😮');
console.info('Shocking, I know.');
console.info('Compatibility chart: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining#browser_compatibility');
}In the FAQ for the optional chaining proposal, it says:
Why does
(null)?.bevaluate toundefinedrather thannull?Neither
a.bnora?.bis intended to preserve arbitrary information on the base objecta, but only to give information about the property"b"of that object. If a property"b"is absent froma, this is reflected bya.b === undefinedanda?.b === undefined. In particular, the valuenullis considered to have no properties; therefore,(null)?.bis undefined.
So that seems to be the intended public-facing answer to this question. The property doesn't exist, and so optional chaining gives you the normal behavior for reading non-existent properties (undefined) without you needing to worry about throwing a TypeError.
Of course, you're not the only one to expect that a?.b should propagate nullishness of a instead. There is quite a lively debate about just what (null)?.b should be in the (now closed) issues tc39/proposal-optional-chaining#65 and tc39/proposal-optional-chaining#69.
In tc39/poc#65 we see that a reddit poll was conducted and the consensus favored "always undefined" over "sometimes null". And in tc39/poc#69 someone did a survey of JS libraries that had function versions of this sort of operator like Undercore's property and Lodash's get, and asked: "if someLibraryFunction({a: 123}, "a") produces 123, and someLibraryFunction(undefined, "a") produces undefined, what does someLibraryFunction(null, "a") produce?" It looks like the answer is undefined for most of the libraries consulted.
Neither of those are necessarily a definitive reason why we have undefined instead of null. But they indicate that the forces of undefined seem to have had some more power or stamina than the forces of null and that undefined ultimately prevailed, always going back to the argument that "a?.b is supposed to let you read the property b of a without worrying about TypeError".