Comments 7
Оператор Check делает из проверки на истинность (значение => true/false) валидатор. А Compose объединяет валидаторы в цепочку. При выполнении цепочка прерывается после первой ошибки.
При проверке лучше возвращать массив с ошибками, что бы вызывающий код мог проанализировать ошибки (коды ошибок? ) и решить надо бросать исключение или нет. И кроме того, удобно когда пользователь может узнать о всех ошибках сразу, а не так что исправил одну, а там следующая «появляется».
Спасибо за доклад по библиотеке.
Все так и есть, но не для Compose, а для Keys и Each — там естественно возвращаются ошибки по всем полям/индексам. Но Compose — это последовательная цепочка валидаторов. Например
Вторая проверка зависит от первой, поэтому имеет смысл прерываться именно после первой. Compose можно рассматривать как and (&&), а Some как or (||).
Compose([isString, Check(str => str.startsWith('a'))])Вторая проверка зависит от первой, поэтому имеет смысл прерываться именно после первой. Compose можно рассматривать как and (&&), а Some как or (||).
У меня после прочтения остались вопросы:
1. Вся валидация работает только на клиенте?
2. Не понял, есть ли возможность задавать правила валидации только для одного параметра, или, например, для двух и более? Например, если у проверяемого объекта есть длина и ширина, то можно ли поставить правило валидации, что ширина должна быть не менее, чем в два раза меньше длины? И в догонку к этому вопросу, если неизвестно, какой именно из параметров нарушает условие, то их надо, вроде как оба отметить, что они не валидны.
1. Вся валидация работает только на клиенте?
2. Не понял, есть ли возможность задавать правила валидации только для одного параметра, или, например, для двух и более? Например, если у проверяемого объекта есть длина и ширина, то можно ли поставить правило валидации, что ширина должна быть не менее, чем в два раза меньше длины? И в догонку к этому вопросу, если неизвестно, какой именно из параметров нарушает условие, то их надо, вроде как оба отметить, что они не валидны.
1. Работает везде, где есть javascript.
2. В том то и дело, что стратегия обработки таких ошибок может быть разная. В случае с травой валидаторы все независимые, но есть варианты как можно передать параметры.
1) использовать контекст (последний параметр) — он будет передан во все валидаторы, т.е. можно извлечь любые данные.
2) можно вначале проверить данные отдельно друг от друга, а затем проверить объект целиком. например:
Я больше за 2 вариант наверно. В траве ошибки — любые js примитивы, а валидаторы — обычные функции, поэтому довольно просто сделать любую обработку.
2. В том то и дело, что стратегия обработки таких ошибок может быть разная. В случае с травой валидаторы все независимые, но есть варианты как можно передать параметры.
1) использовать контекст (последний параметр) — он будет передан во все валидаторы, т.е. можно извлечь любые данные.
2) можно вначале проверить данные отдельно друг от друга, а затем проверить объект целиком. например:
const pointV = Trava([
{
width: isNumber,
height: isNumber,
},
Check((size, ...args) => size.width < size.height), // здесь ошибка вылетит на весь объект, последний элемент в args - контекст
// или например кастомная ошибка на одно из полей (при желании может быть что угодно):
Check(size => size.width < size.height, { height: 'должно быть больше width' }),
]);
const point = { width: 1, height: 2 };
pointV(point, { point }); // передали значение и контекст если нужно
Я больше за 2 вариант наверно. В траве ошибки — любые js примитивы, а валидаторы — обычные функции, поэтому довольно просто сделать любую обработку.
А можно я портирую это на Python?
Sign up to leave a comment.
Травим данные с travajs