Комментарии 13
Подобные декораторам вещи пробовал применять еще на практике и они работают на основе данных из бэкенда, где реализованы данные функции❤
Интересная статья, очень подробно
схема запускает расчет валидации в функции
autorunиз библиотеки MobX
почему не computed?
Это сделано для оптимизации. Навешивать глобально computed на объект, который бы рассчитывал валидацию сразу для всех полей можно, но в таком случае при изменении одного поля, происходил бы полный перерасчет валидации всего объекта. А так можно удобно локализовать необходимые расчеты
Зачем один? На каждое поле - свой компутед валидации
А, я понял о чем вы. Вы правы, можно через решить проблему с компьютед. Но т.к. в схеме есть возможность ручной валидации, в ней есть функции для расчета ошибки. И они же используются в autorun, чтобы просто переиспользовать логику.
Однако, при помощью computed можно было бы переписать расчет условия валидации. Хотя функционально он бы все равно остался таким же, но кода так немного поменьше получилось бы
Скажите, а как на счёт поддержки такого способа в разработке?
Мне такая валидация представляется весьма неполной потому что чтобы её повторить на сервере (сервер же тоже должен всё это проверить в том же объёме?) нужно писать отдельный код для клиента и для сервера, с учётом того, что они делают одно и тоже. (Задача клиента вроде как не перегружать сервер запросами на валидацию и быстрее сообщать пользователю, что что-то не так). Ну, как минимум, сервер делает не меньше. И синхронизация таких клиентской и серверной валидации для десятков полей уже весьма проблематична. Есть ли какие-то варианты кроссовости?
P.S.
Задача валидации очень непростая, хорошо, когда появляются какие-то инструменты с автоматизацией и когда кто-то потрудился её подробно описать, как ваша статья, например. Спасибо.
Я думаю, всегда, когда бэкенд пишется не на JavaScript придется дублировать логику валидации. Но если таки JavaScript используется, схемы можно без проблемы использовать и там. Они не привязаны к DOM'у)
Кстати, в случае использовании схемы и на бэке, и на фронте, можно на бэкенде схемы создавать в ручном режиме, т.к. реактивность там ни к чему. А ещё можно на бэкенде не использовать вообще @watch декораторы, если в них нет необходимости, а на фронте наследоваться от бэковых схем
Понял, спасибо. А нет ли возможности как-то "свести" валидаторы в общий список, чтобы хотя бы посмотреть их в общем? (понимаю, что, вряд ли, но вдруг что-то такое всё-таки есть? Думаю, что заказчики были бы счастливы, если бы был инструмент проверки валидации форм заявленным в ТЗ)
Вам интересны валидаторы, которые применяются на проекте или просто интересно, какими они должны быть? Во втором случае можно зайти на сайт с документацией, там довольно много примеров)
У меня есть собственная система валидаторов, работает и на клиенте и на сервере, но, как вы понимаете - самопал. Но частично решает проблему с синхронизацией кода для клиента и сервера одновременно, плюс для заказчика имеется отдельная таблица, по которой он может проверить и убедиться, насколько валидация соответствует ТЗ. Но хотелось бы найти что-то более совершенное, т.к. самописная несколько устарела - клиент на angularjs уже не совместим с новыми решениями. Поэтому и интересуюсь.
Вообще, конечно, странно, что валидация - очень нужная вещь, а в основном всё какое-то самопальное и слабоинтегрируемое (мой случай тоже).
Как декораторы могут упростить разработку веб-форм