Оглавление
Перед вами статья, которая поможет ответить на вопрос — зачем нужно переопределять дефолтные валидации Spree Commerce? Но для начала — предыстория.
Задача
Работая над e-commerce проектом Saffron, основанном на фреймворке Spree, мы столкнулись с интересной задачей. Клиент пожелал расширить функции интернет-магазина возможностью покупки подарочных сертификатов (Gift Cards). В чем смысл? Представьте: посетитель магазина приобретает подарочную карту, а затем отсылает ее кому-либо из своих знакомых (человеку, который не является пользователем сайта). В результате возникает прекрасная возможность привлечения новых покупателей. Не тех, кто уже зарегистрирован, а лиц, которые впервые зайдут на сайт и прельстятся возможностью получения подарочного сертификата.
С технической точки зрения Gift Card — это разновидность кредита (StoreCredit). Соответственно при создании записи в StoreCredit мы обязаны указать получателя сертификата («user_id»). Но потенциальный владелец кредита еще не зарегистрирован. И нам необходимо решить эту проблему.
Как мы это сделаем? Для начала потребуется создать запись в таблице «StoreCredit». В ней — на поле «user_id» (получатель подарочной карты) — стоит валидация «required: true». Но мы еще не можем ничего туда записать. User_id пока неизвестен (см. выше). И вот тут начинается самое интересное.
Примечание
Вполне возможно, что когда вы читаете эту статью, уже вышел релиз новой версии Spree с Gift Cards. Однако на момент ее написания она находилась на стадии разработки.
Мы опишем все возможные способы сохранения записи в таблице StoreCredit с неизвестным user_id. И выберем оптимальный вариант. Готовы? Поехали. У нас получилось три варианта.
Вариант №1: создание временного пользователя
Мы создаем временного пользователя и связываем запись “StoreCredit“ с ним. После этого, когда покупатель зарегистрируется и заберет подарочный сертификат (т.е, введет код сертификата), мы обновляем поле “user_id” этой записи и удаляем временного пользователя.
Плюсы
- Не надо «играть» с валидациями Spree на бэкэнде;
- Получатель свободен в выборе электронной почты для регистрации.
Минусы
- Мы должны исключить временного пользователя из систем трекинга и аналитики (если таковые имеются);
- Мы должны исключить временного пользователя из почтовых рассылок.
Вариант №2: создание постоянного пользователя с определенным email
Мы можем создать нового пользователя при покупке подарочной карты, используя email получателя и случайно сгенерированный пароль. Таким образом, StoreCredit моментально привязывается к получателю сертификата. После этого ему приходит уведомление на email, и он регистрируется на сайте, используя именно этот email.
В чем разница? В первом случае временный пользователь удаляется, а во втором — получатель карты будет совершать покупки с этого аккаунта.
Плюсы
- Не нужно исключать пользователя из систем трекинга и аналитики;
- Не нужно исключать пользователя из списков почтовой рассылки;
- Не надо «играть» с валидациями Spree на сервере;
- Отсутствие временных пользователей в базе данных (в БД не будет мусорных записей).
Минусы
- Пользователь будет обязан регистрироваться, используя именно тот электронный адрес, который был введен при покупке подарочной карты;
- Если, например, в будущем владелец магазина захочет присылать подарочные карты в бумажном виде по почте, то придется указывать электронный адрес получателя на сертификате — некоторым пользователям это может показаться неудобным или небезопасным с точки зрения сохранности личных данных.
Вариант №3: переопределение валидаций
Мы меняем валидации Spree Commerce на поле `user_id` в таблице StoreCredit.
Плюсы
- Решает все вопросы, связанные с бумажными подарочными картами: клиент свободен в выборе электронной почты для регистрации;
- Не нужно исключать пользователя из систем трекинга и аналитики;
- Не нужно исключать пользователя из списков почтовой рассылки;
- Отсутствие временных пользователей в базе данных (в БД не остается мусорных записей).
Минусы
- Применение этого метода потребует некоторых усилий.
Самое правильное решение не всегда самое простое, и нам пришлось удалить существующие валидации Spree в этом поле таблицы. Но обо всем по порядку.
Как происходит переопределение валидаций в Spree?
Сначала нужно удалить «спришные» валидации, а затем уже добавить свои. Почему? Если вы просто добавите свою валидацию на какое-то поле, она не заменит изначальный вариант, а лишь добавится к нему.
Как все это выглядит:
Вывод
Опробовав три различных варианта решения проблемы, мы пришли к однозначному выводу — лучшим из них является переопределение дефолтных валидаций Spree. Во-первых, он более удобный с точки зрения пользователей. Во-вторых — менее ресурсоемкий для разработчиков. Реализация этого решения дала нам возможность гибкой настройки валидаций в интернет-магазинах, основанных на Spree Commerce.
