千锋Python-晨晨Python：一个简洁且有趣的无限下拉方案( 三 )

newCurrentPaddingTop = currentPaddingTop - remPaddingsVal;
}
}

本文插图

最后是 padding 设置更新以及相关缓存数据更新

// 容器padding重新设置
this.updateContainerPadding({
newCurrentPaddingBottom,
newCurrentPaddingTop
})
// DOM元素相关数据缓存更新
this.updateDomDataCache({
currentPaddingTop: newCurrentPaddingTop,
currentPaddingBottom: newCurrentPaddingBottom
});
思考总结
方案总结：
利用 Intersection Observer 来监测相关元素的滚动位置，异步监听，尽可能得减少 DOM 操作，触发回调，然后去获取新的数据来更新页面元素，并且用调整容器 padding 来替代了本该越来越多的 DOM 元素，最终实现列表滚动、无限下拉。
相关方案的对比
这里和较为有名的库 - iScroll 实现的无限下拉方案进行一个基本的对比，对比之前先说明下 iScroll infinite 的实现概要：

iScroll 通过对传统滚动事件的监听，获取滚动距离，然后：
设置父元素的 translate 来实现整体内容的上移（下移）；
再基于这个滚动距离进行相应计算，得知相应子元素已经被滚动到视窗外，并且判断是否应该将这些离开视窗的子元素移动到末尾，从而再对它们进行 translate 的设置来移动到末尾。这就像是一个循环队列一样，随着滚动的进行，顶部元素先出视窗，但又将移动到末尾，从而实现无限下拉。
相关对比：
实现对比：一个是 Intersection Observer 的监听，来通知子元素离开视窗，只要定量设置父元素 padding 就行；另一个是对传统滚动事件的监听，滚动距离的获取，再进行一系列计算，去设置父元素以及子元素的 translate 。显而易见，前者看起来更加简洁明了一些。
性能对比：我知道说到对比，你脑海中肯定一下子会想到性能问题。其实性能对比的关键就是 Intersection Observer 。因为单就 padding 设置还是 translate 设置，性能方面的差距是甚小的，只是个人感觉 padding 会简洁些？而 Intersection Observer 其实抽离了所有滚动层面的相关逻辑，你不再需要对滚动距离等相应 DOM 属性进行获取，也不再需要进行一系列滚动距离相关的复杂计算，并且同步的滚动事件触发变成异步的，你也不再需要另外去做防抖之类的逻辑，这在性能方面还是有所提升的。

存在的缺陷：

padding 的计算依赖列表项固定的高度。
这是一个同步渲染的方案，也就是目前容器 padding 的计算调整，无法计算异步获取的数据，只跟用户的滚动行为有关。这看起来与实际业务场景有些不符。解决思路：
思路 1、利用 Skeleton Screen Loading 来同步渲染数据元素，不受数据异步获取的影响。即在数据请求还未完成时，先使用一些图片进行占位，待内容加载完成之后再进行替换。
思路 2、滚动到目标位置，阻塞容器 padding 的设置（即无限下拉的发生）直至数据请求完毕，用 loading gif 提示用户加载状态，但这个方案相对复杂，你需要全面考虑用户难以预测的滚动行为来设置容器的 padding 。