АС
И некоторые части написаны очень давно
Size: a a a
2020 September 27
АС
И повлиять на это не возможно, я про это больше имел ввиду когда писал первое сообщение
MA
бекенд на тайпскрипте с шарингом моделей врывается в чат!
Модели у нас и так шарятся, API Gateway у нас на несте. Это не решает проблему валидации пользовательского ввода. Как это всё это связано с graphql, я не понял.. )
K
Модели у нас и так шарятся, API Gateway у нас на несте. Это не решает проблему валидации пользовательского ввода. Как это всё это связано с graphql, я не понял.. )
одним запросом забирать ВСЕ
MA
Кажестя, я потерял нить разговора.. ))) Всё - это что?
K
Да, но лишний запрос не всегда хорошо
вот это
MA
А.. Про graphql. Нет, нам это не нужно.
MA
Там речь шла про другой лишний запрос. Который отправляется, если форма заполнена некорректно. И мы получаем ошибки от бэка. Но это тоже немного не по теме моей проблемы.
MA
Тут суть в том, что полноценная валидация данных у нас должна быть в другом архитектурном слое и не понятно что делать - дублировать её (частично или полностью) в компонентах или писать адаптеры, которые будут использовать логику валидации из слоя бизнес-логики вместе с реактивными формами или что-то еще городить.. ) Думал, может у кого есть опыт решения подобных проблем.
lИ
У нас в проекте валидация "размазана"...
lИ
даже не бэке, допустим есть общий сервис, он на столько общий что .. ню на пример репозиторий и он влидируют типы данных а не всю композицию модели
lИ
всю модель целиком и часто обращается в другие сервисы к косвенно вязанным данным фвасад
lИ
UI при это это уже боль ... приходится дублировать всё, главное что бы изменения вносит впервую очередь в бэк и были тесты, пытаться всё обобщить в отдельном супер валидаторе, мы пришли к мнению что это очень дорого
MA
У нас проект относительно новый и есть возможность делать нормально сразу. С бэком пока не очень, он данные валидирует, но ошибки выводит не всегда корректно. Мы хотим совместно над этим работать. Дублирования логики валидации между бэком и фронтом не избежать, но хотя бы на фронте не хочется ёё размазывать по всем слоям.
K
Я сложную валидацию сделала полностью на беке
K
Он отдаёт некий id проблемного поля и текст
K
А я подсвечиваю эти поля и вывожу ошибку
lИ
у нас на фронте все валидаторы вынесены в сервис отдельный + там же обработке результата валидации с бэка.
контракты на ответ бэка,
состоние
сообщения
путь к полю
и установка по этим данным ерров в контрол формы, который уже выводиться хинтом(мат-еррором)
контракты на ответ бэка,
состоние
сообщения
путь к полю
и установка по этим данным ерров в контрол формы, который уже выводиться хинтом(мат-еррором)
lИ
"путь к полю" самое тухлое место... но вариант получился рабочий, уже получается в 4 проэктах применили такой подход
MA
у нас на фронте все валидаторы вынесены в сервис отдельный + там же обработке результата валидации с бэка.
контракты на ответ бэка,
состоние
сообщения
путь к полю
и установка по этим данным ерров в контрол формы, который уже выводиться хинтом(мат-еррором)
контракты на ответ бэка,
состоние
сообщения
путь к полю
и установка по этим данным ерров в контрол формы, который уже выводиться хинтом(мат-еррором)
Т.е. вы не используете валидаторы из reactive forms?