前段时间有朋友问我一个他们公司遇到的问题, 说是后端由于某种原因没有实现分页功能,所以一次性返回了 2 万条数据,让前端用 select 组件展示到用户界面里,我听完之后立马明白了他的困惑,如果通过硬编码的方式去直接渲染这两万条数据到 select 中,肯定会卡死,后面他还说需要支持搜索,也是前端来实现,我顿时产生了兴趣,当时想到的方案大致如下:
懒加载和分页方式一般用于做长列表优化,类似于表格的分页功能,具体思路就是用户每次只加载能看见的数据,当滚动到底部时再去加载下一页的数据。
虚拟滚动技术也可以用来优化长列表,其核心思路就是每次只渲染可视区域的列表数,当滚动后动态的追加元素并通过顶部 padding 来撑起整个滚动内容,实现思路也非常简单。
通过以上分析其实已经可以解决朋友的问题了,但是最为一名有追求的前端工程师,笔者认真梳理了一下,并基于第一种方案抽象出一个实际的问题:
如何渲染大数据列表并支持搜索功能?
笔者将通过模拟不同段位前端工程师的实现方案,来探索一下该问题的价值,希望能对大家有所启发,学会真正的深入思考。
笔者将通过不同经验程序员的技术视角来分析以上问题,接下来开始我们的表演。
在开始代码之前我们先做好基础准备,笔者先用 nodejs 搭建一个数据服务器,提供基本的数据请求,核心代码如下:
app.use(async (ctx, next) => {
if(ctx.url === '/api/getMock') {
let list = []
// 生成指定个数的随机字符串
function genrateRandomWords(n) {
let words = 'abcdefghijklmnopqrstuvwxyz你是好的嗯气短前端后端设计产品网但考虑到付款啦分手快乐的分类开发商的李开复封疆大吏师德师风吉林省附近',
len = words.length,
ret = ''
for(let i=0; i< n; i++) {
ret += words[Math.floor(Math.random() * len)]
}
return ret
}
// 生成10万条数据的list
for(let i = 0; i< 100000; i++) {
list.push({
name: `xu_0${i}`,
title: genrateRandomWords(12),
text: `我是第${i}项目, 赶快 吧~~`,
tid: `xx_${i}`
})
}
ctx.body = {
state: 200,
data: list
}
}
await next()
})
以上笔者是采用 koa 实现的基本的mock数据服务器,这样我们就可以模拟真实的后端环境来开始我们的前端开发啦(当然也可以直接在前端手动生成10万条数据),其中genrateRandomWords方法用来生成指定个数的字符串,这在 mock 数据技术中应用很多,感兴趣的盆友可以学习了解一下,接下来的前端代码笔者统一采用 react 来实现。
直接从后端请求数据,渲染到页面的硬编码方案,思路如下:

代码可能是这样的
请求后端数据
fetch(`${SERVER_URL}/api/getMock`).then(res => res.json()).then(res => {
if(res.state) {
data = res.data
setList(data)
}
})
渲染页面
{
list.map((item, i) => {
return <div className={styles.item} key={item.tid}>
<div className={styles.tit}>{item.title} <span className={styles.label}>{item.name}</span></div>
<div>{item.text}</div>
</div>
})
}
搜索数据
const handleSearch = (v) => {
let searchData = data.filter((item, i) => {
return item.title.indexOf(v) > -1
})
setList(searchData)
}
这样做本质上是可以实现基本的需求,但是有明显的缺点,那就是数据一次性渲染到页面中,数据量庞大将导致页面性能极具降低,造成页面卡顿。
作为一名有一定经验的前端开发工程师,一定对页面性能有所了解,所以一定会熟悉防抖函数和节流函数,并使用过诸如懒加载和分页这样的方案,接下来我们看看中级工程师的方案:

通过这个过程的优化,代码已经基本可用了,下面来介绍具体实现方案:
1. 懒加载+分页方案
懒加载的实现主要是通过监听窗口的滚动,当某一个占位元素可见之后去加载下一个数据,原理如下:

这里我们通过监听 window 的 scroll 事件以及对 poll 元素使用 getBoundingClientRect 来获取 poll 元素相对于可视窗口的距离,从而自己实现一个懒加载方案。
在滚动的过程汇总我们还需要注意一个问题就是当用户往回滚动时,实际上是不需要做任何处理的,所以我们需要加一个单向锁,具体代码如下:
function scrollAndLoading() {
if(window.scrollY > prevY) { // 判断用户是否向下滚动
prevY = window.scrollY
if(poll.current.getBoundingClientRect().top <= window.innerHeight) {
// 请求下一页数据
}
}
}
useEffect(() => {
// something code
const getData = debounce(scrollAndLoading, 300)
window.addEventListener('scroll', getData, false)
return () => {
window.removeEventListener('scroll', getData, false)
}
}, [])
其中 prevY 存储的是窗口上一次滚动的距离,只有在向下滚动并且滚动高度大于上一次时才更新其值。
至于分页的逻辑,原生 JavaScript 实现分页也很简单,我们通过定义几个维度:curPage 当前的页数,pageSize 每一页展示的数量 * data 传入的数据量。
有了这几个条件,我们的基本能分页功能就可以完成了,前端分页的核心代码如下:
let data = [];
let curPage = 1;
let pageSize = 16;
let prevY = 0;
// other code...
function scrollAndLoading() {
if(window.scrollY > prevY) { // 判断用户是否向下滚动
prevY = window.scrollY
if(poll.current.getBoundingClientRect().top <= window.innerHeight) {
curPage++
setList(searchData.slice(0, pageSize * curPage))
}
}
}
防抖函数实现 防抖函数因为比较简单,这里直接上一个简单的防抖函数代码:
function debounce(fn, time) {
return function(args) {
let that = this
clearTimeout(fn.tid)
fn.tid = setTimeout(() => {
fn.call(that, args)
}, time);
}
}
搜索实现,搜索功能代码如下:
const handleSearch = (v) => {
curPage = 1;
prevY = 0;
searchData = data.filter((item, i) => {
// 采用正则来做匹配, 后期支持前端模糊搜索
let reg = new RegExp(v, 'gi')
return reg.test(item.title)
})
setList(searchData.slice(0, pageSize * curPage))
}
需要结合分页来实现,所以这里为了不影响源数据,我们采用临时数据 searchData 来存储,效果如下:

搜索后:

无论是搜索前还是搜索后,都利用了懒加载,所以再也不用担心数据量大带来的性能瓶颈了。
作为一名久经战场的程序员,我们应该考虑更优雅的实现方式,比如组件化、算法优化、多线程这类问题,就比如我们问题中的大数据渲染,我们也可以用虚拟长列表来更优雅简洁的来解决我们的需求,至于虚拟长列表的实现笔者在开头已经点过,这里就不详细介绍了,对于更大量的数据,比如100万(虽然实际开发中不会遇到这么无脑的场景),我们又该怎么处理呢?
第一个点我们可以使用 JS 缓冲器来分片处理100万条数据,思路代码如下:
function multistep(steps,args,callback){
var tasks = steps.concat();
setTimeout(function(){
var task = tasks.shift();
task.apply(null, args || []); //调用Apply参数必须是数组
if(tasks.length > 0){
setTimeout(arguments.callee, 25);
}else{
callback();
}
},25);
}
这样就能比较大量计算导致的 JS 进程阻塞问题了。
我们还可以通过 web worker 来将需要在前端进行大量计算的逻辑移入进去,保证 JS 主进程的快速响应,让 web worker 线程在后台计算,计算完成后再通过 web worker 的通信机制来通知主进程,比如模糊搜索等,我们还可以对搜索算法进一步优化,比如二分法等,所以这些都是高级工程师该考虑的问题,但是一定要分清场景,寻找出性价比更高的方案。

