Dmitrii
что то я игрался с json schema и как то сырой показалась для валидации
Vitaliy
что то я игрался с json schema и как то сырой показалась для валидации
Ого, внезапно! А чего не хватало? Можно же всегда собственные типы сделать, например :)
Suicide Liza
есть тут кто нибудь кто употребляет jest в vscode как плагин?
Dmitrii
Ого, внезапно! А чего не хватало? Можно же всегда собственные типы сделать, например :)
того что это всетаки json, ситуация когда у тебя есть куча вложенных схем, которые надо шарить между другими схемами, через ссылки, очень неудобно показалось.
Валидация когда у тебя одно поле заивист от других, и может валидироваться по разному, в зависимости от контекста, тоже не густо, ну либо я плохо искал.(еще один минус, не просто найти решение на какой то юзкейс) Тот же yup либо joi, гораздо более гибкие и порог вхождения в них моментальный
Vitaliy
того что это всетаки json, ситуация когда у тебя есть куча вложенных схем, которые надо шарить между другими схемами, через ссылки, очень неудобно показалось.
Валидация когда у тебя одно поле заивист от других, и может валидироваться по разному, в зависимости от контекста, тоже не густо, ну либо я плохо искал.(еще один минус, не просто найти решение на какой то юзкейс) Тот же yup либо joi, гораздо более гибкие и порог вхождения в них моментальный
А скорость исполнения? А вот если делать API — можно схемы валидации использовать для формирования документации swagger. Отдельно рекомендую посмотреть на https://github.com/swagger-api/swagger-node — получается очень крутой вариант, поскольку документация не может разъехаться с имплементацией
A
вот эта регулярка для email - самое то:
/([a-zA-Z0-9_.\-+])+@(([a-zA-Z0-9-])+\.)+([a-zA-Z0-9]{2,})$/
V
А скорость исполнения? А вот если делать API — можно схемы валидации использовать для формирования документации swagger. Отдельно рекомендую посмотреть на https://github.com/swagger-api/swagger-node — получается очень крутой вариант, поскольку документация не может разъехаться с имплементацией
в свашере тоже не все так радужно, но есть описание АПИ и валидация, что +
Dika
вот эта регулярка для email - самое то:
/([a-zA-Z0-9_.\-+])+@(([a-zA-Z0-9-])+\.)+([a-zA-Z0-9]{2,})$/
Это все херня. Берешь /\S+@\w+\.\w+/ и все.
ixplo
Положительные отличия от sass хотел бы услышать
минус, на первый взгляд, такой - переменные визуально не отличаются от названия шрифта, например
CherryTea
Положительные отличия от sass хотел бы услышать
почти не отличаются. из важных для меня фич - стайлус поддерживает много варианция синтаксиса, он в этом плане очень гибок. от обычного css до записей вообще без двоеточий и точек с запятой. И очень нравится как работают миксины, без лишних операторов
CherryTea
минус, на первый взгляд, такой - переменные визуально не отличаются от названия шрифта, например
это не баг, это фича. Так можно раширять уже написанный код
CherryTea
не могу сказать что пользусь этим часто, обычно нужды нету, но приятно что можно написать обработчик на обычное свойство
Дима
Да
Дима
Но он конечно значительно слабее
CherryTea
не могу сказать что пользусь этим часто, обычно нужды нету, но приятно что можно написать обработчик на обычное свойство
скажем, из того что иногда использую:
.foo
absolute: 0 0 10px 10px
выглядит как свойство, а на самом деле миксин который превратит это в 5 свойств css
CherryTea
в теории еще удобно префиксы так писать, но кому это в 2017 нужно
Cenator 🐈
вот эта регулярка для email - самое то:
/([a-zA-Z0-9_.\-+])+@(([a-zA-Z0-9-])+\.)+([a-zA-Z0-9]{2,})$/
<Input type="email" required>- самое то
ixplo
скажем, из того что иногда использую:
.foo
absolute: 0 0 10px 10px
выглядит как свойство, а на самом деле миксин который превратит это в 5 свойств css
а, теперь понятно. но именно этот пример хз зачем )
CherryTea
а, теперь понятно. но именно этот пример хз зачем )
ну чтобы не писать
position: absolute; top: 0; right: 0; bottom: 10px: left: 10px;
Cenator 🐈
Зачем?
V
действительно
Cenator 🐈
Можно сделать это без перезагрузки страницы (и нагрузки на сервак)
CherryTea
Один же хрен на бэке валидировать.
это из серии зачем руки мыть, один хрен все-равно потом опять грязные
V
зачем на бэке чтото валидировать :)
CherryTea
или, зачем в банк звонить, лучше приеду к ним, постою в очереди и спрошу лично
Cenator 🐈
Работу не ищу
Cenator 🐈
Не понял, что за резюме
ixplo
ну чтобы не писать
position: absolute; top: 0; right: 0; bottom: 10px: left: 10px;
а, точно. по диагонали прочёл. интересно, а как миксин этот объявить, если не сложно?
Cenator 🐈
Чтоб отказать сразу, когда искать будешь :-)
За морскую милю обхожу компании, где валидируют формы на бэке)
Aleksand
За морскую милю обхожу компании, где валидируют формы на бэке)
а где нужно? фронтэнд это надежно?
Cenator 🐈
Да
Aleksand
там не будет валидации
Cenator 🐈
Зачем?
Misha
Люди, есть проблема. meteor отказывает создавать папки. Уже 3 часа пробую и ничего
Misha
var fs = require('fs-extra');
Meteor.startup(function () {
fs.mkdirs(__dirname + '/myFolder', (err) => {
if (err) console.error(err);
console.log('pow!!!');
});
});
Misha
Вот пример кода
Aleksand
бэкэнд не должен доверять всему что ему прислали и потому без валидации не выходит
CherryTea
а, точно. по диагонали прочёл. интересно, а как миксин этот объявить, если не сложно?
pos(type, a, b = false, c = false, d = false)
position type
if a b c d
top a
right b
bottom c
left d
else if a b
top a
bottom a
right b
left b
else
top a
right a
bottom a
left a
ixplo
спс
CherryTea
я не спец в sass, но помоему он так не умеет
A
Чтобы тебе в базу говна напихать, например.
лол, тут порой такие советы дают.. кому только эти ребятки приложения пишут
CherryTea
пишут ли
Aleksand
лол, тут порой такие советы дают.. кому только эти ребятки приложения пишут
а ты где валидируешь?
A
я впервые пишу на nodejs, и хочу валидировать на бэкенде
A
так как это правильно
Aleksand
я впервые пишу на nodejs, и хочу валидировать на бэкенде
оно в целом везде одинаково, тут нода прям сильно не аффектит ничего
A
это понятно
A
просто советы а-ля валидируй на фронте, или вообще всё пропускай
Dika
бэкэнд не должен доверять всему что ему прислали и потому без валидации не выходит
Не всегда валидацию есть смысл делать на сервере, когда она нужна только для юзверей.
Aleksand
так как это правильно
ну вот некоторые вещи можно на месте валидировать, большую часть, так и делают. но это не означает что сервер может присланному доверять. и там и там нужна валидация
A
на фронте - простая валидация для проверки пустоты, может минимальный regexp
Dika
Не всегда валидацию есть смысл делать на сервере, когда она нужна только для юзверей.
Например, зачем сравнивать поля Password и Confirm Password на сервере?
Dika
на фронте - простая валидация для проверки пустоты, может минимальный regexp
О такой валидации и шла речь в том разговоре, насколько я понял
Aleksand
на фронте - простая валидация для проверки пустоты, может минимальный regexp
ну есть отилчные компоненты для валидации банковских карт, форматов данных и прочего. это гонять на сервер не нужно, хотя там валидировать то же самое нужно
Lev
Например, зачем сравнивать поля Password и Confirm Password на сервере?
Именно так в вк и зародились лица среднего пола родившиеся в -3876 году
Aleksand
Например, зачем сравнивать поля Password и Confirm Password на сервере?
какое брать? первое второе? или полагать что они одинаковые слепо?
Lev
49 квентебря
Lev
Верните мне мой 2009
Dika
какое брать? первое второе? или полагать что они одинаковые слепо?
Я имею в виду, что нет смысла сравнивать Password === Confirm Password на бэкэнде, а не на фронте.
Aleksand
Я имею в виду, что нет смысла сравнивать Password === Confirm Password на бэкэнде, а не на фронте.
надо и там и там сравнивать
Dika
зачем?
arts
какое брать? первое второе? или полагать что они одинаковые слепо?
Из поля "пароль", очевидно.
CherryTea
ребят вы серьезно? я уже две статьи прочитал, и вы все спорите НАДО ЛИ ВАЛИДИРОВАТЬ
Dika
Aleksand
Это где например?
на фронте сравнить ввод чтобы не гонять лишний запрос, а на бэкэнде проверить что тебе не прислали херню, потому что прислать ее может кто угодно