RK
это вообще хорошая практика для построения отзывчивых интерфейсов
Size: a a a
2020 May 13
И
сначала post api/tickets потом post api/messages
Здесь нет сервисного класса. Но если бы он был?
RK
плохая практика
RK
создал тикет увидел что все ок на фронте создал месседж
RK
проблем 0
RK
даже с точки зрения ux ты всегда сначала тикет создаешь а потом пишешь проблему
RK
или это вообще одна структура
AH
в реальном кейсе можно пример)
Реальный кейс: мне нужно изменить статус заявки (booking), создать привязанный к ней order, к которому создать order_items. И создать джобу о том, что изменения произошли.
В случае если хоть что-то из этого завалится - нужно откатить все изменения из БД и джобу не создавать.
Поэтому в контроллере код обёрнут в транзакции.
В случае если хоть что-то из этого завалится - нужно откатить все изменения из БД и джобу не создавать.
Поэтому в контроллере код обёрнут в транзакции.
И
тикет не имеет смысла без первого сообщения
И
тема + сообщение
RK
Реальный кейс: мне нужно изменить статус заявки (booking), создать привязанный к ней order, к которому создать order_items. И создать джобу о том, что изменения произошли.
В случае если хоть что-то из этого завалится - нужно откатить все изменения из БД и джобу не создавать.
Поэтому в контроллере код обёрнут в транзакции.
В случае если хоть что-то из этого завалится - нужно откатить все изменения из БД и джобу не создавать.
Поэтому в контроллере код обёрнут в транзакции.
вот это уже другое
И
(например)
RK
тикет не имеет смысла без первого сообщения
да понятно, но пользователю то зачем об этом знать?
RK
или группа в телеге без сообщений не имеет смысла?)
RK
имеет конечно
И
так пользователь создает тикет
RK
жмет плюсик создается тикет
RK
пишет сообщение прикрепляется
И
нет