Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save 7iomka/5ceeb18d84329212b6d6225032b29b8d to your computer and use it in GitHub Desktop.
Save 7iomka/5ceeb18d84329212b6d6225032b29b8d to your computer and use it in GitHub Desktop.
Вопросы по статусу заказа.md

Вопросы по статусу заказа

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

export interface OrderPaymentInfo {
  orderStatus: PaymentStatus;
}

Тут orderStatus надо переименовать в paymentStatus

Касательно статуса заказа у нас есть тип

export type OrderStatus =
  | 'DRAFT'
  | 'WAITING_FOR_PAYMENT'
  | 'WAITING_FOR_BANK_TRANSFER'
  | 'PAYMENT_ERROR'
  | 'PAYMENT_SUCCESS';

Нужно пояснение какой статус относится к чему В дизайне предусмотрено 3 экрана

  1. Оплата наличкой: Заказ №{name} успешно создан и ожидает оплаты
  2. Выставлением счёта: Заказ №{name} успешно создан и ожидает оплаты
  3. Оплатой картой:
  • успех Заказ №{name} успешно оплачен

Сейчас у нас обработан только последний пункт - оплата картой. Сберпей в качестве ссылки возврата получает ссылку /payment-info/{id} На этой странице мы дёргаем наш /api-v1/order/${id}/payment который возвращает OrderPaymentInfo и мы чекаем результат, а именно статус type PaymentStatus = 'SUCCESS' | 'WAITING_FOR_PAYMENT' | 'ERROR' и выводим соответствующее сообщение. Пока что обрабатываем SUCCESS и наличие ошибок.

Сейчас стоит задача обработать первые 2 типа оплаты и случай когда пользователь ушёл из сберпея но хочет провести платёж позже. Для последнего я создал ранее страницу order-info в которой дёргаю инфу о текущем заказе /api-v1/order/current и рендерю аналог содержимого третьего шага заказа. Предполагается что ссылка на эту страницу будет нужна в местах где информация о заказе где 'WAITING_FOR_PAYMENT' или 'DRAFT' (пока вроде не вывожу нигде)

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

Если собирать в один то по хорошему всегда зависеть от name заказа (зачастую в UI нам требуется вывести его и в списках и в страницах статуса Заказ №{name} где name это нормализованный красивый айдишник) У нас будет order-info/{name} страница, где мы бы при загрузке чекали некий /api-v1/order/{name} ендпоинт и получали бы сводную информацию о заказе, тоже самое что и /api-v1/order/current сейчас:

interface UserOrderDto {
  id: string;
  userId: string;
  status: OrderStatus;
  paymentType?: PaymentType;
  total: ProductCartTotal;
  isCurrent: boolean;
  products: UserOrderProductCard[];
  productsSortingType: ProductItemSortingType;
  unloads: UserOrderUnloadDto[];
  /** @format date-time */
  createdAt: string;
  /** @format date-time */
  updatedAt: string;
}

на основании который бы отображали бы

  1. если orderStatus 'DRAFT' - тут проблема что у нас нет возможность определить дошёл ли юзер ранее до 3его шага пройдя все валидации или нет. По хорошему при переходе к третьему шагу мне с фронта слать запрос на некий ендпоинт который бы переводил статус заказа в 'WAITING_FOR_PAYMENT' и в случае перехода обратно (назад) в 'DRAFT'. Либо не обрабатывать случаи когда DRAFT, считая такие заказы не резолвенными, вместо этого при выборе конкретного вида оплаты после нажатия на кнопку действия (оплатить / выставить счёт) - бэкенд должен будет менять статус DRAFT на любой из статусов соответственно.
  2. если orderStatus 'WAITING_FOR_PAYMENT' - Заказ №{name} успешно создан и ожидает оплаты и кнопку "оплатить" которая будет менять отображать виджет 3-его шага где юзер выберет тот же вариант оплаты или другой если потребуется.
  3. если orderStatus 'WAITING_FOR_BANK_TRANSFER' - информацию Заказ №{name} успешно создан и ожидает оплаты
  4. если orderStatus 'PAYMENT_ERROR' | 'PAYMENT_SUCCESS' - 'PAYMENT_SUCCESS' - информацию Заказ №{name} успешно оплачен 'PAYMENT_ERROR' - информацию об ошибках (нужны кейсы когда такое возможно вообще, так как сейчас у нас нету кейсов когда бы юзер с сберпея бы перешедши по коллбэку попал бы в ошибку)

Другой вариант когда мы не собираем кейсы в один - чёткое разделение статусов заказа от статусов оплаты В этом случае нужна проработка кейсов с бизнес-аналитиком.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment