TSなアプリケーションも増えてきた昨今、TSでvalidatorを実装する際に何を採用するかは一大トピックです。今回は、その中でも新しめなライブラリでありBlitzも採用しているZodについて見ていきます。firstなvalidationライブラリであるというのがあります。arrayまで)を定義し、それをベースにparseするというものです。公式にあるexampleを見てみましょう。ZodErrorschemaを定義し、schema.parseしてparseできなければエラーを吐きます。objectでも同じです。}z.infer<T>を使うことにより、zodで定義したschemaから型情報を得ることもできます。使い方はシンプルですね。既存の型との整合性をどう取るか?Zodを使うとまず悩むのが、ZodのSchemaと既存の型のダブルメンテ問題です。Firstな設計となっているためです。そのため、何も考えずに実装していくとダブルメンテをしなくてはなりません。z.string()})これでは、フィールドが増えれば増えるほどタイポや入れ忘れによるランタイムエラーを引き起こしやすくなってしまいます。Userにfieldが追加された時にzodSchemaを更新しなくてもTSはエラーになりません。schemaを生成するライブラリです。generatedなロジックに頼りたくないのと、実際のアプリケーションでは型情報以上のvalidationをする機会も多いので、あまり実用的とは思えません。functionを定義する下記のような、既存の型とZodSchemaの型の整合性をチェックする関数を定義してあげます。arg;};これを使えば、既存の型情報と整合性が保たれない場合TSの型エラーを出すことができます。nakamuraTypeScriptエンジニア。Startedのその先へ」を意識した発信をしています。バッジを贈って著者を応援しようバッジを受け取った著者にはZennから現金やAmazonギフトカードが還元されます。2022/11/081年以上前の記事に対して発言失礼します。個人的な見解には以下のように思っています、何か思うことあれば返信いただければです。2023/01/12こちら気づかずすみませんでした。いえいえ、言及ありがとうございます。自分の書き方が分かりづらかったかもしれませんが、もしかすると課題意識が自分と違っているかもです。schemaを作るor保守する際に2重管理的にならざるを得ないのでは、というものでした。schemaとなるわけです。schemaを中心とした設計が成立すると思います。PrismaやhasuraのようなDBソリューションと型生成が一体となったようなツールではDBのスキーマを中心とした設計にするべきなので、zodのschemaに関して「既存の型情報に沿っているよね」ということを担保したいということになります。satisfiesを使うときれいに実装できそうです。truthである場合たしかにその通りですね。置き換え自体がそもそも不可能という観点が抜けていました・・・codegenされた型を使わざるを得ない場合はまさにそうですね。TSならば、という前提の思い込みがありました。2023/03/02良記事ありがとうございます!inferからtypeを作るとtypeのコードが無いので、schemaの設定が間違っていてもわかりづらく、、この記事のようにtypeからschemaを生成するとtypeもちゃんとコードがあるので検証しやすかったです。generatedなロジックに頼りたくないのと、実際のアプリケーションでは型情報以上のvalidationをする機会も多いので、あまり実用的とは思えません。おっしゃる通りでこの方法、最初便利だなーと思っていたのですが、typeに修正が入るたびにgenerateしないとschemaとズレるので怖いなと思いました。functionを定義するこちら便利ですね!typeとschemaの整合性エラーも出してくれて、この方法が一番いいと思いました。satisfiesで代用出来るのも知らなかったです。nakamuraTypeScriptエンジニア。Startedのその先へ」を意識した発信をしています。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。