Clever Geek Handbook

私の失敗の「明るい」未来

カルテットデータ検証ライブラリを1年半作成しています。そして、それは間違いなくありませんでした。それらを修正したいという願望から、メジャーバージョンを再リリースしてアーキテクチャを変更せざるを得ませんでした。そして今、4か月間、最後のメジャーバージョンは変更されていません。しかし、それ自体にも失敗があります。それでは、それらについてお話しします。



真実の唯一の源とDRYの原則



例を考えてみましょう：



import { v } from 'quartet' // V ... ...Validation

interface Person {
    id: number
    name: string
    age: number
}

const checkPerson = v<Person>({
    id: v.number,
    name: v.string,
    age: v.number,
})


この例checkPersonでは、関数、タイプPersonのカスタムTypeGuardです。



繰り返しに気づかずにはいられません。検証の説明は、タイプの説明をほぼ完全に繰り返しますが、ライブラリは、内部で説明されているスキーマが実際にPersonタイプに対応することを保証するものではありません。



これは解決できない問題ではありません。io-tsなど、このプロパティを持つライブラリがあります。



この問題では、保証と検証スキーマの書き込みと読み取りの利便性のどちらかを選択できます。私の意見では、後者の方が望ましいと思います。しかし、それはあなたの好みと間違いの代償に依存します。



無効について説明してください！



説明の仕組みはありますが、その能力を自慢することはできません。例



import { e as v } from 'quartet' // E ... ...Explanatory

const checkPerson = v<Person>({
    id: v.number, 
    name: v.string, 
    age: v.number,
})

checkPerson(null) // => false
console.log(checkPerson.explanations) // []


さて、これはある種の喧嘩です。これはどのような説明ですか？



空のオブジェクトをそこに渡すかどうかを見てみましょう。




checkPerson({})

console.log(checkPerson.explanations)


出力は次のようになります。



[{ value: undefined, schema: '[Function: number]', id: 'value.id' }]


これの方が良い。ただし、この説明はschema関数であるため、シリアル化できません。



. , .



.



. -? , .





— - . , - , - — .



以前に書いたライブラリについて、簡潔さと単純さ、Typescriptとの類似性、パフォーマンスなど、私が気に入っている点はたくさんあります。



しかし今、私は何が悪くなったのかを書くのは良いことだと思いました。おそらく他にもいくつかの欠点がありますが、コメンテーターからの批判を聞いてうれしいです。そして多分私は私の記事を補足します。



読んでくれてありがとう



More articles:


All Articles