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

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
30-Июл-2020 13:31

Цитировать

Я пишу свою библиотеку валидации данных 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, производительность.
Но сейчас, я подумал, что хорошо написать о том, что вышло плохо и недостаточно хорошо, чтобы этим гордиться. Вероятно есть ещё какие-то недостатки, буду рад услышать критику со стороны комментаторов. И возможно дополню свою статью.
Спасибо за прочтение
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_javascript, #_javascript, #_validation, #_opensource, #_javascript

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 17:57
Часовой пояс: UTC + 5