现在的前端项目中对于element-ui的使用几乎已经是一个常规动作了,但是组件库中的ui组件不一定都能满足实际场景的需求,比如今天要讲的select下拉框选择组件。
我们公司是做证券行业基础设施的,股票和证券的数量动不动就是上千,当使用select渲染的时候就会很有压力,我司大致3000条数据,全部渲染出来大致需要4s左右,并且多选模式时,选中和反选时会明显感觉卡顿,这在体验上是觉得不能接受的,所以就开始了优化历程。
方案一:把下拉多选功能做成弹框表格多选
可行性:表格设置selection属性,翻页功能可以解决大数据问题
实际情况:需要展示的字段只要2个即可,对于表格来说太少,显得太空;产品也不同意
弃之~~
方案二:利用select的远程搜索功能,初始化只加载指定数量数据,其它数据通过搜索功能查询
可行性:能满足大数据需求,只是体验上打了点折扣,后台也能支持
实际情况:产品能接受
暂时只想到了这两种方案,和后台商量了一下,具有可实施性,于是采用该方案。
方案分析:
- 问题的根源是一次性渲染太多数据导致卡顿,那么第一次加载的数据就需要找到一个既能最大限度满足业务需求,又能无感加载的临界值,最终我选了300条
- 输入中文搜索时传递queryName作为模糊查询条件
- 如果通过搜索条件勾选了300条以后的数据,失去焦点,重新获取焦点时,需要将已勾选的数