Купон ставки: локальное состояние и подтверждение сервера

Черновик и подтверждённое состояние — разные вещи

Пользовательский stake можно восстановить после reload, но серверный quote нельзя считать вечным. Локальная модель явно разделяет draft selections/stake и confirmed quote. После восстановления draft автоматически запрашивает новый quote.

Порядковый номер на запросах расчёта

Каждое изменение selection или stake повышает локальный request sequence. Ответ применяется только если относится к последней последовательности. Это закрывает классическую гонку: медленный ответ на старую сумму приходит после быстрого ответа на новую.

Задержка реакции не должна делать интерфейс ватным

Запрос quote можно слегка откладывать при наборе суммы, но локальные подсказки — формат, пустое значение, минимальный шаг — показываются сразу. Серверная проверка запускается после короткой паузы или blur, а перед placement выполняется обязательно.

Хранить только безопасный черновик

В storage сохраняются internal selection ids и draft stake, но не «актуальная цена» и не quote token. При старте компонент сравнивает восстановленные selection с текущим market state; закрытые удаляются или помечаются недоступными.

Смена аккаунта в той же вкладке

Локальный betslip не должен мигрировать между разными account context без правила продукта. Storage key включает анонимный/пользовательский scope, а logout очищает персонализированные части. Иначе пользователь видит неожиданное состояние после входа другим аккаунтом.

Граница между удобством и доверием к данным

Хранить локально стоит то, что пользователь ввёл сам: выбранные позиции, черновую сумму, раскрытые группы и другие настройки интерфейса. Цена, лимит, статус рынка и допустимость комбинации принадлежат серверной стороне и должны подтверждаться заново. Это разделение особенно важно после возврата из background, смены аккаунта или восстановления вкладки.

Хороший betslip не делает вид, что всё сохранённое по-прежнему актуально. Он быстро восстанавливает черновик, затем спокойно обновляет серверно-зависимые поля и показывает, что именно изменилось. Пользователь понимает, где сохранён его ввод, а где продукт получил новые условия.

• Не сохранять в persistent storage подтверждённую цену как «актуальную».
• Сбрасывать серверные подтверждения при смене пользователя или tenant-контекста.
• Показывать изменение условий рядом с конкретной selection, а не общей ошибкой формы.

Сценарий, который быстро выявляет неверную границу

Пользователь собирает три selections, меняет сумму, закрывает вкладку и возвращается через минуту. Draft можно восстановить: это удобство. Но вместе с ним нельзя восстанавливать старую цену как подтверждённую. После возврата интерфейс должен заново запросить quote и явно показать, если один рынок уже недоступен или цена изменилась.

Другая проверка — два quote-запроса подряд. Первый отправлен на сумму 100, второй на 150; из-за сети ответ на 100 приходит позже. Если клиент просто применяет «последний полученный ответ», UI откатывается. Поэтому нужен request sequence или иной способ понять, какой ответ относится к актуальному draft. Эта логика естественно живёт внутри Betslip, а не размазывается по отдельным полям формы.

Persist стоит ограничить тем, что пользователь действительно может восстановить без риска: selections, локальная сумма, раскрытые секции. Quote, финальный статус placement и временные server tokens должны восстанавливаться из server authority.

Клиентская часть телеметрия по состояниям, а не по кликам

Полезны переходы draft→quoting→quoted→placing→result и причины отката. Они позволяют увидеть, где пользователь застрял, не записывая содержимое ставки в техническую телеметрию.