null と undefined

全てundefinedにします。理由はオプショナルチェイニングによってnullがundefinedになる非対称性があるから。undefinedとnullを使い分けるくらいならもっと明示的な値を使います。おわり（？） https://t.co/13squvVOfL

— 🈚️うひょ🤪✒📘 (@uhyo_) July 20, 2021

数日前にこのツイートを見て、そのリプ欄にあったリンクを読んだ。

null と undefined - TypeScript Deep Dive 日本語版

undefinedは「初期化されていない」で、nullは「現在利用できない」らしい。

このような基準で null と undefined を選んできたかと言われると、ないなあ……。

null と undefined のどちらであるかをチェックする

どちらもチェックしますという話では、2021-07-02の記事で null と undefined のチェックに==や!=を使うということを学んでいたので理解できていた。

ルートレベルの undefined チェック

ルートレベルのものには使用せずに typeof を利用するらしい、が、どこをルートとしてカウントするのかよく分かっていない。例えば Composition API を使った Vue の SFC だとしたら、Vue.defineComponent({})と同じ階層のこと……？

undefined の明示的な利用の制限

undefined の明示的な利用の制限に関しては、(たぶん)問題ないと思う。例にあるように省略可能プロパティや Optional Chaining を使っているので。

(省略可能プロパティのことをなんていうか忘れてめっちゃググりました)

値の有効性を undefined を使って表さない

これもたぶん無意識だけどクリアしている、はず。

例の関数だと valid かどうかを「undefined なら invalid、そうじゃなければ valid」としているけど、invalid を undefined と表現するのはよくないよ、ということだよね。

ここまで分かりやすい例なら大丈夫かもしれないけど、もしかしたらたまにやってるかも……？怖くなってきたのでちゃんと頭に入れておこう。

JSON とシリアライズ

JSON が null をサポートしていて undefined をサポートしていないので、API とのやり取りでは確実に null になるんだよな。

属性値を undefined にすると、その属性は JSON にエンコードされないため、データのストレージと転送のコストを節約することができます。しかし、これによって、値をクリアすることと、値が存在しないことの文脈を曖昧にしてしまいます。

これ、後半部分のデメリットが多すぎて前半部分のメリットがあまりにも霞んでいる気がする。

結論

JSON は null しかサポートしてないのに null 使わないんかい！となったけど、たぶん逆で、JSON が undefined をサポートしてくれるほうがいいんだろうな……。

Coding guidelines · microsoft/TypeScript Wiki

TS のコーディングガイドラインも読もうと思う。