L'avenir "brillant" de mon échec

J'écris ma bibliothèque de validation de données de quatuor depuis un an et demi maintenant. Et ce n'était pas sans faute. Le désir de les corriger m'a fait rééditer des versions majeures, changer l'architecture. Et maintenant, depuis quatre mois maintenant, la dernière version majeure n'a pas changé. Mais il a aussi ses propres échecs, et maintenant je vais essayer de vous en parler.



La seule source de vérité et le principe DRY



Prenons un exemple:



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,
})


Dans cet exemple checkPerson, une fonction, un TypeGuard personnalisé de type Person.



Nous ne pouvons pas nous empêcher de remarquer les répétitions. La description de la validation répète presque complètement la description du type, mais la bibliothèque ne garantit pas que le schéma décrit à l'intérieur correspond vraiment au type Person.



Ce n'est pas un problème insoluble, il existe des bibliothèques qui ont cette propriété, par exemple io-ts



Dans ce problème, je vois un choix entre les garanties et la commodité d'écrire et de lire le schéma de validation. À mon avis, ce dernier est préférable. Mais cela dépend de vos goûts et du coût de l'erreur.



Expliquez l'invalidité!



Bien qu'il existe un mécanisme d'explication, il ne peut pas se vanter de ses capacités. Exemple



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) // []


Eh bien, c'est une sorte de misère. Quel genre d'explication est-ce ??



Voyons si nous y passons un objet vide:




checkPerson({})

console.log(checkPerson.explanations)


La sortie sera:



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


C'est mieux. Mais cette explication n'est pas sérialisable car c'est schemaune fonction.



. , .



.



. -? , .





— - . , - , - — .



Il y a beaucoup de choses que j'aime dans ma bibliothèque et sur lesquelles j'ai écrit plus tôt: brièveté et simplicité , similitude avec Typescript , performances .



Mais maintenant, je pensais qu'il était bon d'écrire sur ce qui a mal tourné et pas assez pour être fier. Il y a probablement d'autres inconvénients, je serai heureux d'entendre les critiques des commentateurs. Et peut-être que je compléterai mon article.



Merci d'avoir lu




All Articles