纯前端实现sku商品特性选择
前言
- 最近在掘金上看到有好几篇文章在讲电商sku算法问题,体验了下公司mall端对于sku商品的处理。发现每次选择一个特性值都会去请求接口,某个特性值可选和不可选是根据后端下发中的detailStatus字段决定的,如果一个商品特性特别多的情况下,页面还是明显的卡顿,效果如下图。同时也体验了淘宝页面,发现淘宝这部分功能是由前端处理,并非每次都要调用接口。
解决方案
测试数据
|
|
方法一:通过矩形(网上看到的一个关注度较高的方案,有bug)
我们将所有的特性值枚举出来然后形成一个矩阵,交集中为1的表示2个特性值有关联,0表示2个特性值无关联,0和1是根据sku列表转换而来。
如果我们选择了红色,那么纵向为1的点位表示可选,0表示不可选,所以我们很容易就知道,只有套餐二和256G可选
当我们选择紫色和套餐二2个特性值的时候,就是2个长方形取交集(只有都是1的情况下才表示可选),我们可以很清晰的看出只有128G可以选。以此类推当我们选择3个特性值的时候实际就是3个纵向长方形取交集,并且只能取都满足1的点。看到这里我们就知道大致的原理了。
- 代码如下
|
|
|
|
通过以上代码我们获取了一个二维数组,当我选中红色也就是第一列(因为红色的索引为0),第一列中为1的点位表示可选,这些点可以通过映射找到其代表的特性值名称。当我们选择紫色和套餐二的时候就表示索引为1和3的2列,我们只要取这2列的交集就能获取到对应的特性值。
看似完美的解决了问题,但是这种处理方式只考虑到某个特性值的关联关系,没有考虑到2个及2个以上特性值的组合关联关系。所以当我们采用以下数据的时候会存在bug,目前作者还没有找到解决方案。
|
|
方法二:通过过滤的方式筛选节点
方案一的bug是因为没有考虑到2个及2个以上特性值组合由此产生的关联,所以我们是不是可以把选中的节点作为过滤条件取筛选原sku列表,如果某个sku都满足了我们选中的特性值,那么这个sku就是默认可以被选择的。
当我们选择某个特性值的时候,我们对specCombinationList进行循环,获取里面每一项中的specs中是否包含该特性值,然后将满足条件的specs进行concat,然后再进行new Set,这样就能获取到可选的特性值了,
当我们选择红色的时候,我们过滤得到id为1,2,3,4这几个sku的specs中包含红色,那我们就将这些specs合并,同时去重,获取到16G、32G、150ml、300ml、450ml这几个特性值可以选择。
- 当我们选择红色、32G的时候我们发现id为2,3,4这几个sku包含了红色且包含了32G,通过合并和去重之后获取到150ml,300ml这2个节点可选。同时我们还知道了一个价格区间以及剩余库存
|
|
- 效果如下
总结
- 前端现在都是由数据推动页面展示,所以对于数据结构转换等要求比之前要高很多,以前可以更多的需要对dom的api有更多了解,现在需要对数据结构以及算法要有更多的了解。