一文读懂转转通用筛选组件

败特慢

前言由于历史原因，转转/找靓机双卖场各场景（频道页、主搜、首页推荐）、各筛选组件（品牌墙、快筛、抽屉筛、机型筛选）前端展现样式、交互、筛选内容不一致。双卖场筛选数据源不一致，“筛选配置诉求产生”——“配置筛选线上生效”需要多方介入，流程复杂，运营无法闭环。因此，需要统一双卖场各场景筛选的前端表达、后台配置等，对配置流程、运营进行提效。需求背景1.后台可配置转转内部有一个筛选项配置管理后台（如下图所示），可随意新增/配置筛选项，以及筛选项展示的图文配置管理，筛选分类的配置管理，并且实时表现到到前端筛选组件侧。2.统一前端表达定义常见的卖场页面往往包括：搜索区域、Banner区域、筛选区域、商品Feed流区域等。（如下图所示）。其中通用筛选区域的定义主要分为三大区域：细选区、筛选区、快筛区。这三个区域就是“通用筛选组件”需要实现的基础能力。3.一次开发多方复用为了便于转转/找靓机双卖场的快速接入，需要提供一套通用的技术能力与组件方案，并纳入公司内部的公共组件库，便于各场景各页面的便捷接入，减少重复开发。技术背景转转搜索推荐侧提供的schema数据，是由平台侧与搜索侧积累了多年的配置筛选视图与关系控制的一套数据结构体系。内部称之为“Style体系”技术方案（具体数据结构如下图所示）。开发FE筛选组件时，基于现有的“Style体系”Schema进行设计的，相对于站在巨人的肩膀上进行组件的设计与开发，并且该体系方案已经在客户端原生页面线上稳定运行。style体系元数据整体设计设计前期的一些思考：在style体系下，实现一个类似于低代码的jsonschema引擎，只需要关注原子视图，方便开发和维护。参考业界主流的jsonschema引擎，无法满足产品诉求和强交互的效果在style体系下，原子ui组件使用时，约束性很强，比如201只能在200下面出现。因此，没有必要通过引擎方式方式来进行组件树渲染实现，反而会增加工作量，因为jsonschema引擎更适合非耦合性的组件树渲染，也就是组件树中的nodes自由组装，而不进行各个node之间的约束。jsonschema引擎的集中渲染模式，同步迁移到小程序侧时成本大。结合业务场景以及不同方案的技术特点，经过综合考虑，最终采取了传统的SFC组件方式进行设计实现。设计原则：分层思想由于需要封装统一搜索推荐服务能力，并且满足各个筛选区域面板数据流、交互流的处理，保证逻辑清晰，因此对组件进行分层设计，主要分为数据层、服务层、视图层。职责分离组件内部数据模型进行模块化分类，各施其职，方便维护扩展更多能力迪米特法则避免使用全局属性，防止高耦合度，造成无意识的不必要的污染，满足组件复用性。整体架构：架构图主要能力实现模型分层分类策略为了方便对数据模型层进行拉取、管理、聚合处理，针对各个业务能力的数据模型进行了原子拆分。主要分为BizDataModel基础业务数据模型、SchemaModelstyle体系元数据模型、SearchListModel搜索交互缓存模型、LocalModel定位数据模型MobileModel机型模型LegoModel埋点数据模型。//Service层，负责服务端数据获取，model层数据整合exportclassService{ctx:any=nullconstructor(ctx:any){this.ctx=ctx}request(){}queryFilterConfig(){}queryModelFilterConfig(){}getMobileModelData(){}//...}//Model层,负责model的初始化、转换、增删改查等exportclassBizModel{$bizData:FilterParamType=defaultBizDataset(){}get(){}reset(){}}classSchemaDataModel{}//...//SFC层，视图层的各种交互exportdefault{//...data(){constmodelCtx={BizDataModel:newBizDataModel(),SearchListModel:newSearchListModel(),SchemaModel:newSchemaModel(),LocalModel:newLocalModel(),MobileModel:newMobileModel(),LegoModel:newLegoModel(),}constserviceCtx=newService(modelCtx)return{modelCtx,serviceCtx,}}//...}数据模型分层筛选项平铺更新算法平铺更新算法把schemaDataModel作为全局共享数据，方便其他组件获取并调用update方法实现数据高效更新平铺整个筛选组件大JSON数据，辅助后续更新操作，降低整体时间复杂度。在update内部里新建Map数据结构，把平铺好的数据用Map对其进行包裹，提升更新效率每个style粒子都有一个value来标识，但是在快筛和全部筛选中可能会存在value相同，但style不同的情况，它们本质上其实是同一种。这就会出现在100和200下都有次日达筛选项，在100下点击次日达，server会把100和200下的次日达state都置为1，再次点击100下的次日达将取消筛选，但是200下的次日达state仍然为1，导致接口入参又带上了次日达，无法取消选中的情况。我们采用Map可以有效避免这一点，把平铺好的数据用Map处理，就算是value相同也会只取最后一个，这时不用关心Map里存储的是不是正确的，我们会拿update里透传的真实点击项参数去做替换，这样就可以保证传给后端的是最新。筛选组件与搜索框组件联动筛选组件在交互的处理上，需要与顶部搜索框组件进行联动处理。具体交互处理流:交互效果：自动吸顶与滚动组件提供了autoScroll、scrollOffsetTop两个参数，页面滚动采用浏览器原生方法window.scroll。autoScroll控制是否开启点击吸顶、scrollOffsetTop控制滚动的距离。需要注意的是：获取下拉面板要展示的top位置时候，要在页面滚动画结束后执行，DOMscrollapi设计缺陷拿不到动画执行时长。因此需要毛估一个50~100ms,setTimeout延时进行处理。获取当前页面的可滚动距离contentHeightconst bodyScrollHeight = document?.body?.scrollHeight;const documentScrollHeight = document?.documentElement?.scrollHeight;// 确保获取的是页面最大高度 const scrollHeightconst scrollHeight = Math.max(bodyScrollHeight, documentScrollHeight);const clientHeight = document?.documentElement?.clientHeight;// 获取的是页面的可滚动距离 const contentHeightconst contentHeight = scrollHeight - clientHeight;return contentHeight >= 0 ? contentHeight : 0;判断有没有传scrollOffsetTopconst noHasScrollOffsetTop = !this.scrollOffsetTop & +this.scrollOffsetTop !== 0;判断要不要做吸顶// 1. 开启滚动_传了scrollOffsetTopconst hasScrollOffsetTopCase =  !noHasScrollOffsetTop & +canScrollDistance