p.p.s. а еще есть очень занятная штука - conflict free replicated data types. для совсем уж сложных кейсов с синхронизацией стэйта. И в теории можно даже без js такое замутить, просто тупо и сложно

Например система бронирования мест. В форме юзер выбирает место и может ввести скидочный купон. Соответственно если место уже занято, а купон уже просрочен, ему надо вывести 2 ошибки

Например система бронирования мест. В форме юзер выбирает место и может ввести скидочный купон. Соответственно если место уже занято, а купон уже просрочен, ему надо вывести 2 ошибки

сначала место ты бронируешь

Все одним кликом

По кнопке забронировать

еще раз - скидочные купоны - это про оплату. Сначала забронируй

По кнопке забронировать

а выбор места как происходит?)

ты не должен где-то кникнуть?)

Кликаешь на место

ну вот - кликнул - забронировал. Оплата - другая операция

Но заказчик не хочет его блокировать до полного конфирма

Ну короче условие заказчика что все в одно действик

1. вероятность того что чел ввел неправильно промокод сильно меньше вероятности что кто-то, пока он вводил промокод, увел у него удобные ему места

2. заказчику нет дела сколько запросов на сервер у тебя уйдет

Тут вопрос конверсии

Типа так она выше

ну то что ты описал будет работать оч херово. Ибо тебе важно уменьшить период времени когда два человека могут хотеть одни и те же места

и с точки зрения конверсии сервис который мне постоянно показывает ошибки а не делает что я хочу - хуевый сервис и благо есть и другие

короч, то что ты описал - это херово продуманный UX

который ведет к объединению совсем разных операций + увеличивает вероятность конфликтов на ровтом месте

Мы же ре должны от этого зависеть, предметные области могут самыми разными и хотеть много всего

Наше дело придумать как это реализовать

А не доказывать что придуманный интерфейс херовый

не так. твоя задача - проблему решить. Если с решением проблемы тебе приходит бизнес - а ты только формочку сделаешь - это так себе идея поскольку бизнес обычно херовые решения предлагает.

А не доказывать что придуманный интерфейс херовый

ну короч, это твое мнение - у меня чуть другой подход.

Твой подход понятен, интересно еще услышать другие мнения

Я считаю что система должна быть гибкой, если сказали тебе показывать все ошибки сразу, то это не должно вызывать трудностей и противоречить твоей парадигме разработки

Я считаю что система должна быть гибкой, если сказали тебе показывать все ошибки сразу, то это не должно вызывать трудностей и противоречить твоей парадигме разработки

на UI я могу сделать все что захочу. Бизнес не должен накладывать ограничений один это у меня будет http запрос или два

бизнесу нет дела как это работает если итоговый результат одинаков.

p.s. с точки зрения конверсии пользователь не должен ждать отрицательного результата)

Получается что в твоей модели есть некоторая скованность, которую можно решить при помощи ui

Если один чел выбрал место, но потом не стал оплачивать. За это время другой юзер мог это сделать. И потеряли обоих

Получается что в твоей модели есть некоторая скованность, которую можно решить при помощи ui

нет, сковонность я вижу в твоей модели. У меня же руки развязаны за счет того что разные операции остаются разными

Правила игры, инварианты ты берешь у бизнеса. Вот бизнес тебе сказал инвариант, что место нельзя забронировать, а потом указать купон. Вполне себе разовая операция, бронирование с указанием купона. Но эта операция требует 2 проверок для сохранения корректности инварианта.

Одна операция не всегда означает одну проверку

билет на самолёт купить проще, чем на вашем замечательном сервисе что-либо) вот те и минусы российского бизнеса: постоянно вылезет обезьяна, которая знает как испортить жизнь клиентам ещё сильнее, чем есть)

Правила игры, инварианты ты берешь у бизнеса. Вот бизнес тебе сказал инвариант, что место нельзя забронировать, а потом указать купон. Вполне себе разовая операция, бронирование с указанием купона. Но эта операция требует 2 проверок для сохранения корректности инварианта.

это инварианты разных агрегатов

точнее даже не так - в случае с промокодами это даже не инвариант. Это прекондишен

Вот и как результаты проверок этих прекондишенов показать юзеру?

Вот и как результаты проверок этих прекондишенов показать юзеру?

делаешь формочку выбора места, а потом формочку оплаты. Правда я не знаю как в случае неоплаты разлочить забронированное место =\

делаешь формочку выбора места, а потом формочку оплаты. Правда я не знаю как в случае неоплаты разлочить забронированное место =\

Большинство сервисов резервируют место на Х минут. Нет оплаты - резерв снят.

Большинство сервисов резервируют место на Х минут. Нет оплаты - резерв снят.

ну вот он хочет типа кто успел тот и успел

делаешь формочку выбора места, а потом формочку оплаты. Правда я не знаю как в случае неоплаты разлочить забронированное место =\

выше ответили. 10 минут без оплаты - всё, иди в лес

да нет никакой проблемы с тем что бы делать это дело одной операцией. есть проблема в том, что промокот вылазит и увеличивает период времени когда все может пойти пиздой

ну вот он хочет типа кто успел тот и успел

Такая задача не имеет решения, т..к слишком многое влияет на скорость - от скорости интернета до скорости биллинга (непрогнозируемый результат).

и @Justmozg не может мне объяснить почему я не могу проверить валидность промокода заранее

Такая задача не имеет решения, т..к слишком многое влияет на скорость - от скорости интернета до скорости биллинга (непрогнозируемый результат).

не, решение есть - называется блокировки.

просто кто-то пойдет лесом

и как по мне это очень неудобно и вообще попахивает нежеланием разработчиков подумать

не, решение есть - называется блокировки.

Ну так я это решение и озвучил. Даже не всуе будь он упомянут Вордпресс - и тот не даст двум разным юзерам редактировать одновременно одну и ту же статью: одного из них выкинут.

ну это я называю плохим UX

и допускаю такое только в ситуациях когда конкуренции по данным не предвидится. Что не правда в случае букинга мест в кино каком

сделать же синк стэйта между клиентами в целом задача тривиальная

Вот и как результаты проверок этих прекондишенов показать юзеру?

вот тебе другой кейс. - пользователь выбрал место - пользователь ввел промокод - пользователь ввел "оплатить картой" - пользователь кликнул "забронировать" - пользователя кинуло на систему оплаты (внешняя система) где он может провести до 15 минут

в какой последовательности система должна работать

после того, как спустя 10 минут сбер тебе прислал смску с кодом, ты возвращаешься на сайт и видешь, что билет уже куплен кем-то более быстрым)

- сначала забронировать место - проверить промокод - потом перекинуть на оплату - если любой пункт зафэйлился - отменить бронь - оплата считается "зафэйленной" если подтверждения оплаты не поступило в течении 15 минут (и лимит на платежку тоже стоит)

после того, как спустя 10 минут сбер тебе прислал смску с кодом, ты возвращаешься на сайт и видешь, что билет уже куплен кем-то более быстрым)

именно

то есть от этого правила - бронь в течении N минут всеравно не уйти

единственный вариант - привязывать карточку или покупать каккую-то внутреннюю валюту - но с точки зрения конверсии я бы нахуй такой сервис послал

ну меня, как пользователя, устраивает разумные минут 15 для чекаута. если там гонки на время, то нахуй идут

гибкий как говно сервис

Это все так. Речь не о времени оплаты, а о принципиальном условии делать все проверки одновременно после совершения клика по кнопке и выдаче результатов проверок в понятном виде пользователю

Это все так. Речь не о времени оплаты, а о принципиальном условии делать все проверки одновременно после совершения клика по кнопке и выдаче результатов проверок в понятном виде пользователю

проверки "одновременно" сделать невозможно. Просто потому что это разные операции которые проистекают последовательно

сначала тебе всеравно надо проверить бронь. И только потом промокоды

особенно если у промокодов есть лимит на количество применений (скажем первые 1000 человек по промокоду "пидр" получают скидку 20%)

Верно, но как выполнить эти проверки без ексепшенов чтоб они обе выполнились

Изначально нас об этом спросили, делать отдельный метод или как то хитро ловить эксепшены

если у тебя зафэйлился первый этап - нет смысла проверять на второй потому что ты не можешь воспользоваться промокодом

как следствие - будет только одна ошибка

возьмем мой кейс с многоразовыми промокодами: прекондишены: - промокод должен существовать - промокод можно применить еще один раз инварианты - количество применений промокода не должно привышать N раз

Но проверить то все равно можно, независимо от выбора места. Почему бы сразу и не сказать об ошибке.

ну так скажи сразу - до того как пользователь нажал "забронировать"

ему даже кликать не надо - ввел в поле - проверил на прекондишены. Более того, если на момент брони нельзя воспользоваться промокодом - скажи об этом чуваку на чекауте

но не отменяй бронь

(большинство будут продолжать заказ - увеличим конверсию. Отменим- они не будут продолжать с большей долей вероятности)

То есть должен быть метод типа isValidCoupon, возвращающий тру или фолс, и клиент должен вызвать этот метод, и этот же метод должен вызываться в методе чекаута

это ж типичные трюки маркетологов. Например ситуация в которую я попал пару месяцев назад когда была акция местной авиокомпании со скидками. Они сделали скидки так что скидка в популярные даты была только либо на "туда" либо на "обратно". И я выбрав интересующие меня даты увидел скидку не в 50% а в 25% по итогу. И я был близок к тому что бы плюнуть и купить как есть. Просто потом подумал что "бля, вообще не выгодно"

То есть должен быть метод типа isValidCoupon, возвращающий тру или фолс, и клиент должен вызвать этот метод, и этот же метод должен вызываться в методе чекаута

нет, в методе чекаута должна попытка применить купон

с блокировками и всем таким

не вышло - хер с ним. Идем дальше

Эта попытка не должна проверять валидность?

запоминаем просто что не вышло что бы предупредить пользователя

Эта попытка не должна проверять валидность?

"проверять валидность" - что ты под этим подразумеваешь? просто я часто вижу людей которые сначала стэйт меняют а потом проверяют. У меня же стэйт не может впринципе стать невалидным.

типа.... apply() { if (!this.atLeastOneRemain()) { throw new UnableToApplyPromocode(this.id) } this.remember(Promocode.applied(this.id)) }

сам промокод ничего не знает о других операциях - он обработал свою исключитетльную ситуацию. Дальше ты можешь ловить исключение, собирать их в список, делать другие операции - это промокодам не интересно

можешь юзать ивенты (что бы отменить бронь, или не отменять)

А если надо проверить возможность применения купона без применения купона?

А если надо проверить возможность применения купона без применения купона?

то это операция чтения

и вообще можно другую модель для этого юзать

полная свобода

такие проверки никогда не спасут тебя от пограничных сценариев (когда два чувака одновременно пытаются потратить последний промокод)

Я считаю что система должна быть гибкой, если сказали тебе показывать все ошибки сразу, то это не должно вызывать трудностей и противоречить твоей парадигме разработки

Сказали сверху идея так себе для так себе систем. В этой ситуации можно просто забить на качество, все решения приходят сверху же,, они уже продуманя(нет). Все операции должны быть для конкретных юзкейсов и юзкейс это не бронировать только после оплаты, а бронировать. Заказчику не нравится, что место висит заброненное после, так может поменять скрины местами, вначале блокировка денег, а потом выбор места или отмена блокировки? Для таких решений надо иметь аналитику/статистику, иначе гадание на кофейной гуще

Если один чел выбрал место, но потом не стал оплачивать. За это время другой юзер мог это сделать. И потеряли обоих

Сколько времени проходит между двумя операциями? Как часто в день/час такое происходит?

Место нужно бронить только после ввода всех данных и перехода на внешнюю систему оплаты. Сначала блочить деньги не вариант.

Место нужно бронить только после ввода всех данных и перехода на внешнюю систему оплаты. Сначала блочить деньги не вариант.

как часто у тебя люди невалидный промокод вводят?

Технически проблем с этим нет. Вопрос как грамотно выразить в коде все проверки

Технически проблем с этим нет. Вопрос как грамотно выразить в коде все проверки

ну у тебя проблема с тем что ты хочешь зачем-то получить список всего что пошло не так

как будто бы у тебя это нормальная ситуация - когда что-то идет не так в количестве больше одного косяка на операцию