こんにちは！フロントエンドの現場を渡り歩いてきた、ちょっとおせっかいなシニア・アーキテクトです。
JavaScriptを触り始めて、「あれ？なんか動かないぞ」「思ってたんと違うデータが入ってきたぞ」って頭を抱えた夜、ありませんか？……大丈夫、それ、この世界を通ってきた人なら全員が通る「お約束の関所」ですから、安心してください。
今日は、そんなJavaScriptの沼にハマりがちな「データ型の判定（これは一体なにものなんだ！？）」について、実務の現場目線でぶっちゃけトークを交えながらお話しします。
特に、自前でがんばって書く型判定と、世の中のすごい人たちが作った「型判定ライブラリ（Lodashの`is`系とか）」をどう使い分けるべきか、その裏側まで丸裸にしちゃいましょう。
—
そもそも、JavaScriptの「型」ってなんでそんなに気まぐれなの？
お買い物を想像してみてください。
レジに「リンゴ」を置けば店員さんは「これは果物ですね」と分かりますよね。でも、JavaScriptくんはちょっとおっちょこちょいです。
「`100`（数字）」という数字を渡したつもりが、いつの間にかまわりが文字列の海に囲まれて「`”100″`（文字）」に化けていたり、「空っぽですよ」を意味するはずの `null` や `undefined` が、機嫌によってひょっこり現れたりします。
この「変幻自在すぎるデータたち」の正体を正確に見破るのが、型判定というお仕事です。
—
1. 私たちが最初に出会う「罠」：`typeof` の限界
JavaScriptを学び始めると、まず最初に `typeof` という魔法の言葉を教わりますよね。
// さあ、調べよう！
console.log(typeof 42); // “number” （よし、数字だ！）
console.log(typeof “こんにちは”); // “string” （よし、文字だ！）
「なんだ、`typeof` さえあれば安心じゃん！」って思いますよね？
……ここからが、JavaScriptの闇（愛すべきクセ）のはじまりです。
「配列（Array）」を調べると、裏切られる事件
実務で一番ビビるのがこれです。リストデータを表す「配列」を `typeof` で調べてみてください。
const ユーザーリスト = [“佐藤”, “鈴木”, “高橋”];
// さあ、何と返ってくるでしょうか…？
console.log(typeof ユーザーリスト);
// 答え： “object” （えっ、オブジェクト！？ 配列じゃないの！？）
そうなんです。JavaScriptの世界では、配列も「中身がちょっと特殊なオブジェクト」扱いなんです。これを知らずに「`typeof` が object だから配列だね！」なんてコードを書くと、本番環境で盛大にバグの花火が打ち上がります。気をつけてくださいね。
さらに言うと、歴史的バグとして `typeof null` が `”object”` を返すなど、`typeof` は「ざっくりした仕分け（荷物の大体の大きさ）」には使えても、「正確な正体当て」には全然頼りにならないんです。
—
2. 自前で完璧な型判定をやろうとすると…沼にはまる
「じゃあ、自分で完璧な判定関数を作ってやろう！」と意気込むプログラマが通る道があります。いわゆる `Object.prototype.toString.call()` という呪文です。
// 自前で配列かどうかを完璧に判定する関数
ifu (value) {
return Object.prototype.toString.call(value) === ‘[object Array]’;
}
……うーん、見た目がちょっと呪術的ですよね。
実はこれ、JavaScriptの内部的な「住民票の正式名称」を暴き出すプロ技ですが、実務でこれをすべてのデータ型（日付、正規表現、エラー、Map、Set……）の分だけ毎回書くのは、正直なところ車輪の再発明（すでに誰かが作った車輪を、わざわざ木から削り出す作業）になっちゃいます。
毎日のようにこんな複雑な判定コードを書いていると、開発の手が止まってしまいますよね。
—
3. そこで登場するのが「プロの便利グッズ」：Lodashなどの型判定ライブラリ
現場のプロたちは、こういうめんどくさい「型のゆらぎ」に毎回悩まされたくありません。そこで登場するのが、Lodash や is.js といったユーティリティライブラリです。
例えば、みんな大好き（？）な Lodash なら、こんな風に書けます。
import _ from ‘lodash’;
const データ = [1, 2, 3];
// 「これ、配列ですか？」が一発で分かる！
if (_.isArray(DATA)) {
console.log(“ちゃんとした配列ですね！安心！”);
}
// 「これ、空っぽのオブジェクトですか？」も一発！
if (_.isEmpty({})) {
console.log(“中身は空っぽです！”);
}
ライブラリを使うメリット（現場の生の声）
1. バグを踏む確率が劇的に減る
私たちが思いつかないような「変なデータ（IEの古い仕様や、ブラウザをまたいだデータなど）」の例外処理が、ライブラリの中にはすでに何重にも仕込まれています。先人たちの知恵の結晶です。
2. コードが「人間語」になる
`Object.prototype.toString.call(…)` なんて読みにくいコードの代わりに `_.isDate(val)` と書いてあれば、コードを読むチームメイトが「あ、日付をチェックしてるんだな」と一瞬で理解できます。
じゃあ、デメリットはあるの？
「じゃあ全部ライブラリに頼っちゃえ！」となりそうですが、ちょっと待って。
もし、たった1行の `Array.isArray()` を使いたいがために、巨大なライブラリを丸ごと読み込んでしまうと、Webサイトの表示スピード（パフォーマンス）が重くなってしまいます。特にスマホで見るユーザーにとっては、無駄なデータをダウンロードさせられるのは痛手です。
—
💡 今日のまとめ：どう使い分ければいいの？
迷える子羊たちのために、シニアアーキテクトからの実践的な処方箋を置いておきますね。
- 現代の標準機能で足りるものは、そのまま使う
- 配列かどうか： `Array.isArray(value)` （これ、もう標準で使えます！）
- 文字列や数値など、単純なプリミティブ型： `typeof` でもOK
- 複雑なオブジェクト、日付、空判定、ブラウザ間の差異が怖いときは
- `Lodash` などの信頼できるライブラリの、必要な関数だけ（ツリーシェイキングやピンポイントで）をインポートして使う。
JavaScriptの型判定は、最初は意地悪に感じるかもしれませんが、仕組みが分かってくると「おっ、今回はこういうデータだな」と可愛がれるようになります。
完璧を目指して最初から一人で背負い込まず、先人たちの便利な道具も上手に頼りながら、楽しくコードを書いていきましょう！
あなたのフロントエンドライフが、少しでも軽やかになりますように。
コメント