TypeScriptコンパイラはなぜオプションの連鎖とヌル結合演算子、?.および??、から
// x?.y
x === null || x === void 0 ? void 0 : x.y;
// x ?? y
x !== null && x !== void 0 ? x : y
の代わりに
// x?.y
x == null ? void 0 : x.y
// x ?? y
x != null ? x : y
?
おそらく、舞台裏では== null同じ 2 つのチェックが行われますが、コードの長さを考慮しても、単一のチェックの方がすっきりしているようです。オプションの連鎖の文字列を使用する場合、追加される括弧も大幅に少なくなります。
ちなみに、オプショナルチェーンがコンパイルされないことにも驚きました
x == null ? x : x.y
保存するnullvs.undefinedこれにはその後答えが出ています:JavaScript のオプション チェーンでは、null を保持する代わりに undefined を使用するのはなぜですか?
ベストアンサー1
信頼できる答えは以下にあります。マイクロソフト/TypeScript#16（古いですね）具体的にはこのコメント:
これは
document.all、下位互換性のために言語内で特別な扱いを受ける癖 [...] のためです。document.all == null // true document.all === null || document.all === undefined // falseオプションの連鎖提案では
document.all?.foo === document.all.fooしかし、
document.all == null ? void 0 : document.all.foo誤って が返されますvoid 0。
だから、特定の特異な、廃止された、時代遅れの、奇妙な、遺産疑似プロパティ型のエッジケースHTMLAllCollection誰も使用していないもので、 または と大まかに等しいが、厳密にはまたはnullと等しくありません。すごい!undefinednull
誰も真剣に検討していないようだ速報のものになりますdocument.all。また、このxxx === null || xxx === undefinedバージョンはすべての状況で機能するため、仕様に従って動作する下位互換性のある JS コードを生成する最も簡単な方法であると考えられます。