支付宝小程序内实现瀑布加载（上拉、下拉以及异常情况处理）总结

[shiiiiiiji]

这篇写的比较细，主要是针对同类业务一个比较细的总结，肯定有更好的实现方案，而且也有很多需要改进的地方。

瀑布式加载（也称分页加载）是移动端页面一种比较常见的列表呈现方式，之前大致总结过在实现过程中需要注意和考虑的一些点：前端实现瀑布流列表考虑点总结 。

简单说来，即初始加载第一页数据，当用户往上滑动屏幕时，出现“正在加载中”文案，并异步请求第二页数据，请求完成后隐藏“正在加载中”文案，继续滑动时如果发现所有数据全部请求完了，就显示“亲，就这么多了”，并且用户再上滑时不会再触发请求。同理，当用户滑到列表最顶部时，出现“下拉刷新”文案，拉取最新数据，覆盖或拼接到页面最顶部。

具体下来，其实里面有很多细节需要考虑：

• 是全局列表还是局部列表（即列表区域滚动时其他区域是否带动页面其他区域滚动）
• 第一页列表是否需要异步请求，如果需要异步请求时是否和上拉时的文案“正在加载中”保持一致，即效果类似于上拉，只不过初始没数据而已
• 初始数据未满一屏，最底部是否显示“亲，就这么多了”
• 当上拉或者点击另外tab时（多tab列表），是否初始化列表显示“正在加载中”文案
• 当网络异常情况下，如何控制页面的UI，一直loading，还是以体验更加好的方式呈现给用户。如下图：
  

对于细节点来说，其实可以理解为列表处于某种状态，而在不同的状态下每一块的UI展示和以及状态间的逻辑维护是比较麻烦的，在使用jQuery或者React实现时，因为对页面的控制权比较大，可以借助在页面上获取的信息能够比较直观和直接维护，但是在小程序环境下，需要完全从数据的角度去维护页面的状态，是比较复杂的。

在支付宝小程序下，用到的一些组件和方法如下：

• scroll-view组件：滚动容器，提供容器滚动时的一些信息和事件（onScrollToLower-滚动到底部/右边，会触发 scrolltolower 事件），但需要注意的是，前提必须给容器一个**“固定”的高度（上下滑）或宽度（左右滑）（至于为什么在这里打引号，是因为我们可以利用flex布局，给一个自适应的“固定”高度**）
• 因为支付宝小程序不支持组件开发，仅提供UI层面的模板功能，所以可以把“正在加载中”、“亲，就这么多了”、“无结果页面”、“异常页面”封装成一个template，但是逻辑还是需要写在页面的js里，因此复用性以及可维护性极差。
• 状态如何明确：
  • 如何确定用户拉到或快拉到了底部：通过scroll-view的 scrolltolower 事件
  • 因为“亲，就这么多了”，在列表未满一屏时不要显示，如何确定列表满了一屏：通过scroll-view的scroll事件，只要页面滚动了，就能说明页面已满一屏
  • 是否有下一页：每一次异步请求服务端都会返回此状态，或者根据返回列表的长度与pageSize比较
  • 是否在加载中：只要发出请求就手动设置为加载中状态，直至请求成功或失败，否则用户一直触发上拉操作时会发出多个请求，造成状态混乱。
  • 是否断网：相较于H5，小程序拥有更强大的原生系统能力，比较容易获取到系统设置的联网状态，我们在app层设置一个状态，在具体page中就可以在需要判断网络状况时实时获取最新的联网状态。

另外，当列表中某一项的图片加载失败时，如何将其设置为默认图片：这在H5上是很好做到的，我们只要在每一个img标签上绑定onerror事件，触发时将当前img标签的src属性修改为默认图片即可。但在小程序中是不存在DOM概念或者说很难操作页面上的DOM（亲测，查询DOM特别慢），而必须通过data（类似于react中的state）来管理，但是页面列表是不固定的，当触发onerror时如何修改相应的data看起来是不可能完成的。后来换了个思路，设定一个空的图片加载异常状态数组，由其和真实的listData共同来确定每一个image组件的src属性，一旦触发onerror事件，就给数组push一个指定条目（一般是id或者code）的标记，这样就能够准确替换出错的图片了。