我失败的“光明”未来

我一直在写我的四重奏数据验证库了一年，现在是一半。这并非没有失败。修复它们的愿望使我重新发布了主要版本，改变了体系结构。现在，四个月以来，最后一个主要版本都没有改变。但是它也有其自身的失败，现在我将尝试向您介绍它们。

真理的唯一来源和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相似，性能。

但是现在，我认为写出坏事并不足以引以为傲的事情是件好事。可能还有其他缺点，我将很高兴听到评论员的批评。也许我会补充我的文章。

谢谢阅读