Oops... your message was not sent

Your message has been successfully sent

тематические истории, основанные на опыте компании JetRuby
Электронная коммерция

Переопределение валидаций в Spree Commerce: случай из практики

Перед вами статья, которая поможет ответить на вопрос — зачем нужно переопределять дефолтные валидации Spree Commerce? Но для начала — предыстория.

Задача

Работая над e-commerce проектом Saffron, основанном на фреймворке Spree, мы столкнулись с интересной задачей. Клиент пожелал расширить функции интернет-магазина возможностью покупки подарочных сертификатов (Gift Cards). В чем смысл? Представьте: посетитель магазина приобретает подарочную карту, а затем отсылает ее кому-либо из своих знакомых (человеку, который не является пользователем сайта). В результате возникает прекрасная возможность привлечения новых покупателей. Не тех, кто уже зарегистрирован, а лиц, которые впервые зайдут на сайт и прельстятся возможностью получения подарочного сертификата.

SV-1

С технической точки зрения 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.

department
Статью подготовил
Отдел Электронной коммерции
Команда имеет богатый опыт в разработке онлайн-решений для бизнеса. Мы используем только самые передовые технологии из области электронной коммерции.
New Articles