Я пишу свою библиотеку валидации данных quartet уже полтора года. И не обошлось без фейлов. Желание их пофиксить заставляло меня заново и заново выпускать мажорные версии, менять архитектуру. И сейчас уже четыре месяца последняя мажорная версия неизменна. Но и в ней есть свои фейлы, и сейчас я о них попытаюсь рассказать.

Единственный источник истины и принцип 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 — функция, пользовательский TypeGuard типа Person.

Мы не можем не заметить повторений. Описание валидации повторяет описание типа почти полностью, но библиотека никак не гарантирует, что схема описанная внутри действительно соответствует типу 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, производительность.

Но сейчас, я подумал, что хорошо написать о том, что вышло плохо и недостаточно хорошо, чтобы этим гордиться. Вероятно есть ещё какие-то недостатки, буду рад услышать критику со стороны комментаторов. И возможно дополню свою статью.

Спасибо за прочтение

«Светлое» будущее моих фейлов