Как стать автором
Обновить

Комментарии 8

По вашей ссылке как раз пример громоздкого решения, подобного тому, о котором я писал в первом абзаце.
Там предлагается для каждой формы делать что-то такое:
Replace the onclick function call of the form’s “Continue” button:
onclick="shipping.save()"
with
onclick="trackAndSaveShipping()" 
Это порождает кучу дополнительного кода, который еще нужно и во все шаблоны пораспихивать, а учитывая что форм в том магазине сотни (кабинет клиента, корзина, оплата, пожертвования, спец.подписки, отзывы, рейтинги, блог, корпоративные клиенты и т.д.) — это был бы жуткий гемор.
Мой вариант позволяет отслеживать ошибки во ВСЕХ этих формах с помощью всего нескольких строк кода в единственном файле!
Я не говорю, что ваше решение хуже или повторяет представленное решение. Моя была о том, что оба решения опираются на использование стандартной валидации и уже из этого начинаются все остальные пляски.
Вот как раз стандартная валидация там применяется меньше чем в половине форм.
Я же написал, что в JS лапше т.н. сторонние разработчики нагородили своих обработчиков-валидаторов — что как раз сильно усложняло эту задачу!
Т.к. если бы использовалась только стандартная валидация — я мог бы просто перекрыть один ее метод и все, т.е. тогда задача была бы тривиальной и писать было бы не о чем.
:) Не буду что-либо оспаривать и доказывать не посмотрев кода.
А зачем код смотреть? Просто представьте, что кроме стандартного валидатора в большинстве форм используется еще несколько десятков кустарных кастомных валидаторов — жесть!
Слава богу, что представитель заказчика, отвечающий за дизайн сайта, требовал единообразия стиля всех форм на сайте и в случае невалидного заполнения поля требовал добавления CSS класса 'validation-failed' к таким полям (что соответственно единообразно показывало пользователю, что поле на странице заполнено неверно).
Вот за этот факт я и ухватился — иначе пришлось бы для каждого кастомного валидатора писать отдельный код для трекинга ошибок валидации.
Я вам говорю про то что мы имеем с коробки. А с коробки мы имеем валидатор, который оперирует css селекторами элементов.
Про то что делают другие разработчики я не говорю, и глубоко уверено, что если разработчики пытаются изобретать велосипеды не посмотрев, что уже есть и чем можно воспользоваться — это плохой разработчик стиль кодирования. А код смотреть нужно для того, чтобы сказать так ли необходимо было изобретать новые валидаторы или достаточно было воспользоваться стандартным прототайповским.
Сайт из моей статьи как и большинство реально эксплуатирующихся сайтов — далеко не из коробки.
Как правило на таких сайтах за несколько лет эксплуатации собирается жуткий зоопарк сторонних и самописных модулей и тем. Код их далеко не идеален и с этим ничего не поделаешь.
Мне заказали не редизайн сайта или рефакторинг кода, а конкретную задачу — трекать ошибки в полях форм в GA — все!
Для тех, кому попадется подобная задача я и написал эту статью, с целью показать возможное простое решение.
Т.е. если вы не поняли — статья не о том, как нужно было писать код всем плохим разработчикам, чтобы хорошему разработчку было легко решить поставленную задачу, а о том как хорошему разработчику можно по простому решить задачу, если приходится иметь дело с плохим кодом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации