なぜ今さら「プリミティブ型」なのか？——伝説的アーキテクトが説く、JSの「基礎という名の深淵」
やあ。現場でコードを書いていると、ついフレームワークのライフサイクルや最新のビルドツールの設定に目が行きがちだよな。だが、フロントエンドで「なぜかバグる」「なぜか状態が予期せぬ更新をする」といったトラブルの9割は、このJavaScriptの根幹である「データ型」の理解不足に起因している。
今日は、中級者の君たちがもう一度立ち返るべき「プリミティブ型」の真実について話そう。教科書的な定義をなぞるだけなら誰でもできる。現場で戦うための、JSの解像度を一段上げる話をしようか。
—
1. プリミティブ型：7つの「不変」なる戦士たち
JavaScriptにおけるプリミティブ（原始型）とは、「オブジェクトではないもの」を指す。言語の仕様レベルでメモリ上に直接値を保持する、いわばJSという城の石垣のような存在だ。
現在のJSには以下の7つが存在する。
1. String: 文字列。
2. Number: 倍精度浮動小数点数。
3. BigInt: 巨大な整数。
4. Boolean: 真偽値。
5. Undefined: 未定義。
6. Symbol: 一意な識別子。
7. Null: 「空」であることを示す値。
ここで最も重要なのは、これら全てが「不変（Immutable）」であるという点だ。
「不変」の真の意味
「文字列を書き換えた」と思っているとき、実はメモリ上では「既存の文字列を書き換えた」のではなく、「全く別の新しい文字列を作り出し、変数の参照先をそちらに付け替えた」だけなんだ。この「メモリの消費」と「ガベージコレクション（GC）の挙動」を意識できると、ReactやVueなどの状態管理において「なぜオブジェクトを直接ミューテートしてはいけないのか」という深淵が理解できるようになる。
—
2. 現場で使える「型判定」のベストプラクティス
`typeof` 演算子、便利だよな。だが、こいつには歴史的な負債がある。
// 現場でよく遭遇する「typeofの罠」
console.log(typeof null); // “object” が返る。これはJS初期のバグだが、仕様として残っている
console.log(typeof []); // “object”
console.log(typeof {}); // “object”
// 正確に判定するための関数。これくらいはユーティリティとして持っておこう
const getType = (value) => {
// Object.prototype.toString.call を使うのが最も確実だ
return Object.prototype.toString.call(value).slice(8, -1).toLowerCase();
};
console.log(getType(null)); // “null”
console.log(getType(100n)); // “bigint”
console.log(getType(Symbol())); // “symbol”
この `getType` 関数は、どんな複雑なプロジェクトでも必ず役に立つ。`typeof` に頼り切って、`null` でバグを生むような若手には、このコードを見せてやってくれ。
—
3. 実務で知るべき「BigInt」と「Symbol」の使いどころ
中級者なら、`Number` と `BigInt` の違いは押さえておくべきだ。`Number.MAX_SAFE_INTEGER` を超えるような巨大なID（例えばTwitterの雪崩式IDなど）を扱う場合、`Number` だと精度が死ぬ。
// BigIntの活用例：精度の高い計算
const bigNumber = 9007199254740991n;
console.log(bigNumber + 1n); // 9007199254740992n
// 注意：NumberとBigIntは混ぜて計算できない
// console.log(bigNumber + 1); // TypeErrorが発生する
また、`Symbol` は「プロパティ名の衝突を避ける」という点だけでなく、ライブラリ開発や、外部から直接書き換えられたくない隠しプロパティをオブジェクトに持たせたい時に極めて強力だ。
—
4. 最後に：なぜ「型」を意識するのか
君たちが書くコードは、ただ動けばいいわけじゃない。ブラウザのエンジンがどう解釈し、メモリをどう確保し、どうやってGCが不要になったオブジェクトを回収するか。その「裏側」を想像できる人間だけが、パフォーマンスを最適化できるんだ。
プリミティブ型は、JSの最も純粋な構成要素だ。ここを曖昧にしていると、どんなに高度なアーキテクチャを組んでも、足元から崩れる。
次のプルリクエストを出すとき、自分が扱っている変数が「本当にその型であるか」、そして「その操作によってメモリに無駄な負担をかけていないか」を一瞬だけ考えてみてくれ。その「一瞬の思索」が、君をただのコーダーから、真のエンジニアへと引き上げるはずだ。
また何か詰まったら、いつでも聞きに来るといい。現場の泥臭い話、いくらでもしてやるよ。
コメント