- 澁川喜規
- 約 2,100 文字
- 4,000 View
いろんなJavaScriptの統計を見ると、今時のウェブフロントエンドの新規開発は80%はTypeScriptになっているということです。また、TypeScript自身を使わなくても、TypeScriptで培われた型推論のパワーで、JavaScriptであってもVSCode上で補完とか思いの外うまくいったりしちゃうので、TypeScriptフレンドリーというのはますます重要になっています。
ですが、TypeScriptが有効なのはコンパイル前とか実装中であり、実行時に流れてくるJSONが果たしてきちんとした型通りの定義なのかはTypeScriptの範疇外です。そこでZodとかのバリデーションを行ってくれるライブラリが使われます。Zodを使えばJSONが規定通りの構造をしているか確認した上で、TypeScriptの型を持った変数に安全に代入してくれます。
ですが、JSONというのはネットワーク上を流したり、ファイルに保存したりには便利ですが、扱えるデータの種類が限られるため、実行中のプログラムからするとパースしてそのまま使うのが決して最適とは言えません。UUIDや日付が扱えなくて文字列になってしまったりします。そのための仕組みがZodにはいくつかあります。
最後の項目のやり方を知りたくて調べ始めたのですが、ついでにシンプルな変換とかロジックを加えて変換というのもついでに整理しておきます。
シンプルな値の型だけの変換
名前を変えずに組み込み型を使って日付(.date())や文字列(.string())、数値(.number())とかに変換するだけなら、いつもの型の間に.coerceを挟むだけでOKです。
const userSchema = z.object({ |
ちょっとロジックを加えて変換
UUIDは128ビット(16バイト)のデータを、文字列表記にして扱うことが多いのですが、文字列にすると36文字になります。大量にUUIDがある場合に少しでもサイズを小さくするためにJSON上ではbase64で22文字表記にするが、TypeScriptの場合に文字列表記で扱いたい、みたいなケースです。この場合は次に説明するpreprocess()も使えますがちょっと長くなるので割愛します。
function convertBase64ToUUID(src: string, ctx: z.RefinementCtx) { |
transform()を使う場合、来る値は文字列だ、というところまではzodが保証した上で変換関数を呼んでくれます。その中身の変換だけに注力すればOKですが、場合によっては変換中にエラーが発生する可能性があります。ここではbase64として不正な文字列が渡ってきた、長さが足りないというケースのエラーハンドリングをしています。
構造を変える
次のような配列がサーバーからは送られてくるが、プログラム中ではidをキーにしたMapで扱いたい、ということがあると思います。
{ |
とりあえずそのまま実装してみたのがこの形です。preprocess()のコールバックの第1引数は未知の値なのでunknownです。unknownから文字列に変換するのは自分で型ガードを実装しても良いですが、ここもZodを使った方がお手軽なので使っています。ここでもポイントはsafeParse()を使い、エラーがあったら先ほどと同じくctxに登録してあげることです。
const originalType = z.array( |
ジェネリックにしてみる
似たような変換処理がたくさんある場合、1つの変換関数でやりたいですよね?
id属性を持たないオブジェクト型を定義して、それを渡すと、preprocess()が受け取れる変換関数と、第2引数の型定義の両方を作って返す、arrayToMap()関数にしました。先ほどの例は、id以外にnameしか属性がないオブジェクトだったのですが、複数の属性があるケースもあると思うので、結果の型はMap<string, string>ではなく、Map<string, { name: string }>と先ほどとは違う型になるようにしています。
const originalType = z.object({ |
まとめ
Zodでの簡単な値単位の変換はネット上で調べると公式含めてすぐ出てきたのですが、配列のMap変換とエラーハンドリングの仕方がなかったのでやり方を調べるついでにまとめてみました。
エラーがあった場合は変換関数の第2引数のctxにエラー情報を登録するのが肝だな、と思うのですが、最初試した時は無邪気に safe() を使って例外を投げるコードを書いていました。これでも userSchema.parse() では違和感なく使えるのですが、呼び出し元で userSchema.safeParse() 形式で呼び出すと、本来の使われ方とは異なって例外が投げられてしまうので、このようにエラー処理を書く必要がありました。
外部とのインターフェース部分でより安全にデータを扱ったり、プログラム側のつまらない変換処理をオフロードすることで、プログラム側の責務がわかりやすくなったり、Zodを使いこなすとフロントエンドのコードは綺麗になりますね。まあZod関連のコードはその分、ごちゃごちゃになりがちで、臭いものには蓋になってしまうかもしれませんが、そういう割り切りで良いのかな、と思っています。