关于前端:优惠券流程

小程序优惠券流程

优惠券流程大抵如下：

优惠券发放模式

优惠券个别通过支付的模式发放，也能够通过用户的状态来主动发放优惠券。

主动发放的优惠券实用于一些流动，比方：回归流动用户登录主动发放优惠券。

手动支付的优惠券，用户通过点击支付的模式取得。

优惠券通常有多种形式，而且优惠券的数量不限，例如：满减优惠券，同类型的满减优惠券能够获取多张，满 50 减5、满 100 减10，除了满减优惠券外还有折扣优惠券，这些优惠券都能够反复支付，一个类型的优惠券能够取得多张。

优惠券应用

用户应用优惠券的时候会有限度，例如：同类型的优惠券只能应用一张，如果用户当初有 满减优惠券 x2、折扣优惠券 x3，那么用户的在应用的时候 一个类型只能应用一张。

个别状况下，用户应用优惠券的时候会有一个初始的 最优优惠券抉择 ，不须要用户手动抉择应用哪一张，在获取或者应用的时候，后盾会 主动调配 好以后条件下的 最优优惠券搭配 。其次是用户能够 手动抉择 本人想要应用的那一张。用户在抉择优惠券的时候，只有优惠券的 抉择产生更改 ，那么以后的计算 金额也要随之产生更改，这样优惠券和金额就是动静且实时的计算，用户才晓得以后优惠券到底优惠了多少，最初理论须要领取的金额是多少。

优惠券的应用场景

1、商品抉择

2、商品详情

3、订单领取页

4、购物车页

5、……

优惠券在这么多场景下都会反复呈现，那么，该优惠券实际上能够 封装成一个组件，在对应的页面引入组件即可，所有抉择的逻辑、搭配的逻辑以及弹窗展现的信息，都在该组件内操作，组件内操作完，返还给页面的就是最终抉择的数据，页面通过返回的数据进行展现即可。

优惠券应用以及领取

优惠券抉择后会主动计算金额，那么计算金额的接口参数应该有 商品 id、商品数量 、 优惠券 id，通过这些参数申请计算金额接口。参数的构造如下：

let params = {
    goodsArr = [{ goodsId:100 , quantity : 1},  // 商品 id 数量
    {goodsId:101 , quantity : 1}
    ],
    discount =  [32001,32001]  // 优惠券的 id 汇合，不同类型的券 id 都放在这里
}

申请计算金额接口后，后盾返回的数据如下：

{
    code: 200
    data: {
            disMoney: 1.5,  // 优惠金额
            totalPrice: 20,  // 总金额
            actualPrice: 18.5, // 理论金额
            isDis : 1  // 是否应用优惠券
    }
    message: "SUCCESS"
}

该金额就是理论须要领取的金额，如果要领取，领取接口的金额数据就依据计算金额返回的数据申请。

领取
在领取的时候，其实波及到一个 领取归滚 的问题，如果用户抉择了优惠券，在付款的时候勾销了，那么该优惠券会去哪里呢？如果用户 勾销领取 ，那么该订单会去 待付款 页，券还是跟商品绑定了，处于已抉择的状态，如果领取胜利，该优惠券 -1，如果勾销领取，优惠券会从新加回来。

领取失败
如果从购物车走领取流程，用户如果领取胜利，购物车须要删除对应商品；
如果用户在领取的时候勾销领取，购物车也应该删除对应商品，因为该商品会走待付款流程；
总结下来就是：用户走购物车发动的领取，只有发动领取了，购物车对应的商品都应该删除。

优惠券抉择
不同类型的优惠券其实是有个分类 id 的，同类型的优惠券只能有一张，其实就是通过分类 id 来做判断，如果折扣优惠券有 3 张，用户抉择了其中一张，另外两张就得勾销选中状态，其它的优惠券也是同样的逻辑。