`Object.is()` が暴く「等価性」の嘘：なぜ我々は `===` を疑わねばならないのか
フロントエンドの深淵を覗き込んでいる諸君、ようこそ。
日々の開発で何気なく叩いている `===`（厳密等価演算子）。我々はこれを「JSにおける正義」と信じて疑わない。しかし、ブラウザのエンジンが解釈するメモリ上のバイナリ表現と、言語仕様が定義する「等価」の間には、時として埋めがたい溝が存在する。
今回は、あえてその「綻び」に焦点を当てたい。ECMAScript 6で導入された `Object.is()` が、なぜ単なる比較演算子の代替品ではなく、アーキテクトにとっての「最後の砦」となり得るのかを解説しよう。
—
1. `===` が見捨てた「特異点」
まずは現実を見よう。我々が信頼する `===` には、IEEE 754浮動小数点数規格の亡霊が取り憑いている。
// 誰もが知る、しかし無視されがちな「狂気」
console.log(NaN === NaN); // false
console.log(+0 === -0); // true
「`NaN` は何とも等しくない」という仕様は、数学的には一理あるかもしれない。だが、データバリデーションやステート管理を行うエンジニアからすれば、これは悪夢だ。例えば、計算結果が `NaN` になったことを検知しようとして `if (result === NaN)` と書いてしまう若手がいれば、即座に修正させなければならない。
`Object.is()` は、この「比較の不整合」を解決するために生まれた。
// Object.is() による真実の追求
console.log(Object.is(NaN, NaN)); // true
console.log(Object.is(+0, -0)); // false
// メモリ上の構造が完全に一致するかを判定する
const obj = { a: 1 };
console.log(Object.is(obj, obj)); // true
console.log(Object.is({ a: 1 }, { a: 1 })); // false (参照が異なるため)
2. なぜアーキテクトは `Object.is()` を選ぶべきなのか
「`===` で十分じゃないか？」と思うかもしれない。だが、大規模なWebアプリケーションを設計する際、この僅かな挙動の差が致命的なバグを生む。
キャッシュとメモ化（Memoization）の罠
Reactの `useMemo` や `React.memo` の内部実装を覗いたことがあるだろうか？ 実は、Reactのレンダリング最適化における依存配列の比較には、内部的に `Object.is` (あるいはそれに準ずるアルゴリズム) が使われている。
もし、あなたが実装した計算ロジックが、意図せず `-0` を生成し、それがステートとして保存された場合、`===` を使った比較ロジックは常に「変化なし」と誤判定し、UIが更新されないという不可解な現象を引き起こす可能性がある。これはデバッグが極めて困難な「サイレント・バグ」の典型だ。
状態管理ライブラリとイミュータビリティ
Reduxのようなライブラリで `selector` を書く際、`Object.is()` を活用することで、不必要な再レンダリングを完璧に排除できる。特に、複雑な数値計算を伴うグラフライブラリや、物理演算を行うフロントエンドアプリケーションにおいては、`-0` を許容するか否かが、描画エンジンの計算負荷に直結するのだ。
3. 実務レベルでの「使い分け」の哲学
もちろん、すべての比較を `Object.is()` に置き換えるべきだと言っているわけではない。パフォーマンスと可読性のバランスが重要だ。
- `===` を使うべき場面:
- 一般的なプリミティブ値（文字列、ブール値）の比較。
- ブラウザの最適化が強力に効くホットパス（ループ内部など）での比較。
- `Object.is()` を使うべき場面:
- 数値計算の結果を扱うライブラリや関数の内部。
- `NaN` が発生しうる境界値の判定。
- Reactのカスタムフックや、厳密な状態比較が求められるイミュータブルなデータ構造のハンドリング。
/
- 高度なバリデーション用ユーティリティ
- 値が本当に「同じ」かを、IEEE 754の制約を超えて判定する
/
const isStrictlyEqual = (a, b) => {
// 基本はObject.isで安全に比較
return Object.is(a, b);
};
// 使用例：数値計算の厳密な監視
const calculatePosition = (val) => val 0;
const result = calculatePosition(5); // 0 になるはずが、何らかの過程で -0 になる可能性
if (!isStrictlyEqual(result, 0)) {
console.warn(“数値の精度に異常を検知。レンダリングをスキップします。”);
}
最後に：エンジニアとしての矜持
JavaScriptは、その柔軟性ゆえに、書き手の「細部へのこだわり」がそのままアプリケーションの堅牢性に直結する言語だ。
`===` を使うとき、あなたは「この値は `NaN` にならないはずだ」という前提を置いている。しかし、`Object.is()` を選ぶとき、あなたは「不確定な未来のデータに対しても、私は正しい挙動を保証する」という宣言をしていることになる。
優れたアーキテクトとは、言語の「仕様の隙間」を埋め、どんなエッジケースが訪れても動じないコードを書く者のことだ。今日から、比較演算子を叩くその指先を、少しだけ鋭くしてみてほしい。
そのわずかな「こだわり」の積み重ねこそが、最高峰のプロダクトを作るための唯一の道なのだから。
コメント