「なぜ、まだ `null` で消耗しているの？」——TypeScriptの `strictNullChecks` が守る、現場の平和とエンジニアの矜持
フロントエンドの現場で、一度は経験があるはずだ。
「`Cannot read property ‘map’ of undefined`」
このエラーを目にした瞬間、深夜のオフィスで心が折れそうになったことはないだろうか。JavaScriptという言語は、自由と引き換えに、ある種の「爆弾」を常に抱えている。その爆弾の正体こそが、暗黙的な `null` や `undefined` の混入だ。
今日は、TypeScriptにおける最も重要、かつ「これさえあれば、とりあえず安心」と言える最強の防御壁、`strictNullChecks` について話をしよう。
—
1. なぜ `strictNullChecks` が「必須」なのか
`tsconfig.json` の設定において、`strict: true` を有効にしていれば自動的にオンになるこのオプション。もし君のプロジェクトでこれが `false` になっているなら……今すぐ設定を変えて、テストコードが落ちるのを見て絶望する準備をしてほしい。
なぜなら、このオプションが `false` だと、TypeScriptは `null` や `undefined` を「あらゆる型に代入可能なもの」として扱ってしまうからだ。
// strictNullChecks: false の世界
const name: string = null; // エラーにならない。これが悲劇の始まり。
console.log(name.length); // 実行時エラー：Cannot read property ‘length’ of null
TypeScriptの美学は「コンパイル時にバグを撲滅すること」にある。`strictNullChecks` を有効にすると、型システムは「値が存在しない可能性がある」という事実を、厳格にコードの構造へと昇華させる。
—
2. ブラウザの裏側で起きていること
少しだけ低レイヤーの話をしよう。ブラウザのJavaScriptエンジン（V8など）は、メモリ管理において「値が存在しない」状態を `null` や `undefined` という特殊な値で表現する。
開発者が「ここは必ず値が入るはず」と信じていても、APIの仕様変更や通信エラー、予期せぬDOMの状態によって、ブラウザは無慈悲に `null` を返してくる。型システムがこの「存在しない可能性」を無視していると、エンジンはそのまま処理を継続し、メモリ上の不正なアドレスを参照しようとして実行時エラーを吐く。
`strictNullChecks` を有効にすると、コンパイラは「値が null である可能性があるなら、その先でメソッドを呼ぶな。まずはチェックしろ」と強制するようになる。これが、実行時のクラッシュを防ぐ最も強力な防波堤だ。
—
3. 実践：現場で使うべき「安全な記述」
では、実務ではどう書くべきか。ここでは、よくある「APIから取得したユーザーデータ」を例に、現場レベルのテクニックを紹介しよう。
interface User {
id: number;
name: string;
email?: string; // 存在しない可能性があるプロパティ
}
// APIからのレスポンスをシミュレート
const fetchUser = (): User | null => {
return Math.random() > 0.5 ? { id: 1, name: “Taro” } : null;
};
const user = fetchUser();
// 1. オプショナルチェーンによる安全なアクセス
// 値があれば返し、なければ undefined を返す。エラーにはならない。
console.log(user?.email?.toUpperCase());
// 2. if文による「型ガード」
// ここで null チェックを行うと、スコープ内では user は User 型として確定する
if (user) {
console.log(`User name is: ${user.name}`);
} else {
console.warn(“ユーザーが見つかりませんでした”);
}
// 3. Nullish Coalescing (??) によるデフォルト値の付与
// null または undefined の場合に右辺を採用する
const userName = user?.name ?? “ゲストユーザー”;
console.log(userName);
なぜこれが「プロのコード」なのか？
- オプショナルチェーン (`?.`): 冗長な `if` 文を排除し、コードの可読性を劇的に高める。
- 型ガード: コンパイラに対し、「このスコープ内では安全だ」という情報を明示的に与えることで、型推論を最大限に活かす。
- Nullish Coalescing (`??`): `||`（論理和）演算子とは異なり、`0` や `””`（空文字）といった「値としては有効な偽値」を誤って上書きしない。これこそが、実務でハマりやすいポイントを回避する賢い書き方だ。
—
結論：守りを固めて、攻めに集中せよ
`strictNullChecks` を有効にすると、最初はコンパイルエラーの嵐に遭うかもしれない。しかし、そのエラーは「今まで見過ごされていた潜在的なバグ」を、TypeScriptが一つひとつ丁寧に教えてくれているサインだ。
「動くコード」を書くのはジュニアでもできる。しかし、「壊れないコード」を書くのが、我々フロントエンド・スペシャリストの仕事だ。
プロジェクトの `tsconfig.json` を開いてみてほしい。もし `strictNullChecks` がまだなら、今すぐ有効化しよう。最初は少し泥臭い作業になるかもしれないが、その先に待っているのは、デバッグに追われない、静寂で平和な開発環境だ。
君のコードが、今日もどこかのブラウザで静かに、そして確実に動き続けることを願っている。健闘を祈る。
コメント