JavaScriptの型判定という「終わらない迷宮」を攻略する
やあ。フロントエンドの現場で泥水をすすってきた君なら、一度は経験があるはずだ。「`typeof null` が `’object’` になる」「配列の判定で `typeof` を使ったら死ぬ」といった、JavaScriptの愛すべき、しかし時に殺意を覚える仕様たちに。
今日は、ライブラリ開発や堅牢なフロントエンド基盤を作る際に避けては通れない、「実務における型判定のベストプラクティス」について話をしよう。
なぜ、安易な `typeof` や `instanceof` が罠なのか
まず大前提として、JavaScriptの型システムは「緩い」。これがこの言語の最大の武器であり、同時に最大の落とし穴だ。
多くの駆け出しエンジニアは、とりあえず `typeof` を使う。だが、中級者であれば「ブラウザの裏側で何が起きているか」を想像しなければならない。`typeof` はあくまで演算子であり、その値が内部的にどういうビット構成で保持されているかを返しているに過ぎない。
例えば、`null` が `’object’` になるのは、JS誕生初期のバグがそのまま仕様として凍結されているからだ。`instanceof` に至っては、iframeを跨いだり、異なる実行コンテキスト（Realm）を行き来した瞬間に「偽」を返す可能性がある。これでは、ライブラリの境界線で使う判定ロジックとしてはあまりに脆い。
実務で信頼できる「型判定の黄金律」
僕が現場で必ず実装するのは、Objectプロトタイプの `toString` を利用した堅牢な判定関数だ。これこそが、JSの内部仕様を逆手に取った「正攻法」といえる。
/
- どんな環境でも型を正確に射抜くための汎用ユーティリティ
- @param {unknown} value – 判定したい値
- @returns {string} – 小文字の型名 (‘string’, ‘number’, ‘array’, ‘null’ etc…)
/
const getType = (value) => {
// Object.prototype.toString.call(value) は、
// “[object Array]” や “[object Null]” といった文字列を返す。
// これを加工して、扱いやすい形に正規化する。
const rawType = Object.prototype.toString.call(value);
return rawType.slice(8, -1).toLowerCase();
};
// 使い方
console.log(getType(null)); // “null” (typeofだとobjectになる)
console.log(getType([])); // “array” (typeofだとobjectになる)
console.log(getType(/regex/)); // “regexp”
このアプローチの素晴らしい点は、実行コンテキスト（iframe等）を跨いでもその実態を正確に捉えられることだ。ライブラリ開発において「外部から渡されたデータが何か」を確信するために、これ以上の近道はない。
防御的プログラミング：型チェックを「ガード」として使う
さて、判定関数を作ったら、次はそれをどう使うかだ。ここで「防御的プログラミング」の真骨頂である、タイプガード（Type Guard）を紹介しよう。TypeScriptと併用している現場も多いだろうが、JSネイティブでも考え方は同じだ。
/
- 設定オブジェクトを安全にマージする関数の例
/
function mergeConfig(base, custom) {
// 1. まずは型を絞り込む（ガード節）
if (getType(base) !== ‘object’ || getType(custom) !== ‘object’) {
throw new TypeError(‘設定値はオブジェクトである必要があります’);
}
// 2. 続いて、プロパティの存在チェック
// 現場では「あるはずのキーがない」ことによるランタイムエラーが一番多い
const keys = Object.keys(custom);
for (const key of keys) {
if (getType(custom[key]) === ‘undefined’) continue;
base[key] = custom[key];
}
return base;
}
ここで重要なのは、「例外を投げることを恐れない」という姿勢だ。
中途半端に `undefined` を返して後続の処理で `Cannot read property ‘x’ of undefined` を発生させるよりも、型チェックの段階で明確に例外を投げ、スタックトレースを残したほうがデバッグは圧倒的に速い。
最後に：JSの「暗黙の型変換」とどう付き合うか
JavaScriptには `==` (等価演算子) による暗黙の型変換がある。これに対して「絶対に使うな」と教える現場も多いが、シニアの視点から言えば、「なぜその変換が起きるか」を理解した上で、意図的に使うならアリだ。
例えば、`if (value == null)` と書けば、`null` と `undefined` の両方を一度に弾ける。これは、フロントエンドでAPIレスポンスの「値が存在しない状態」をチェックする際には非常に強力な武器になる。
ただし、チームでこれをやるなら「なぜ厳密等価（`===`）を使わなかったのか」をコメントに書き添えること。それが、君のコードを「動くゴミ」から「保守可能な資産」へと変える最後の仕上げだ。
型判定は、ただの「チェック」ではない。それは、君のコードが受け入れるデータの境界線を定義する「契約」なんだ。この意識を持つだけで、君が書くコードの質は一段上のレベルに達するはずだよ。
さあ、エディタに戻ろう。次はどんな複雑なデータ構造と戦うつもりだい？
コメント