mint-ui分页上拉加载与浏览器的兼容性

在前言开始之前，如果你想用mint-ui作为vue的移动ui框架，我给你的建议是换一个(理由是这个项目活跃到冰点)。当然，这丝毫不影响我们对浏览器兼容性的探索。积累经验就是抓住任何机会。
很久以前，在使用mint-ui mobile框架时，我发现分页上拉loadmore组件在某些浏览器中无法正常工作(上拉无法加载下一页)。很惭愧的说，我之前以为是一些老机器的低版本浏览器的问题，完全忽略了。我简单写了一个vue minuti分页实现，大致触及了浏览器兼容性的一些问题。
有兴趣可以看看：https://eminoda.github.io/2018/09/04/vue-mintui-page/
最近高频也有类似问题，甚至是chrome，急需解决。借此机会，再次浏览loadmore组件，探索真相。
兼容滚动条距离的ScrollTop判断
这是第一个兼容性问题，你可以从这个PR了解问题的原因：
https://github . com/eleme Fe/mint-ui/commit/e 7 e 6 f 0 B1 ACC 766 e 009 DFA 670 e 8 a2 ADC 091 DC 2 a 68
一对
原因是不同的浏览器厂商对scrollTop的认可度不同。
先搞清楚scrollTop是什么意思。
当页面内容过长时，浏览器会提供滚动条来存储这个溢出的页面。ScrollTop是从元素到窗口可见内容顶部的距离(如果没有发生垂直滚动，则值为0)。
虽然很多文章都列出了不同浏览器对scrollTop的支持，但是如果没有相关的版本信息，就无法确定随着浏览器的更新是否还像现在这样列出。下面我列举几个我测试过的浏览器(主要是移动端，当然是以小米为模型)
浏览器对scrollTop的支持
排版原因，详细信息单独列出：
浏览器详细信息
可以看到，Chrome浏览器无法获取scrollTop中document . document element . scroll top上的值，导致mint-ui判断是否在页面底部加载的逻辑“失败”，导致上拉加载失败。
只要在原审判决的基础上做如下处理：
这还不是全部。因为个人喜好，我一般都在搜狗浏览器开发，不过值得一提的是，虽然搜狗也用了和Chrome一样的内核，但是无法获得这个属性的值(很神奇)。结果一直主观认为Chrome这样的浏览器不会有兼容性问题。
当然也可以使用window . page offset(window . scroll)，上面测试的所有浏览器都支持。
另外，我还把UC浏览器列为特例，因为即使判断逻辑正确，仍然存在上拉加载的问题，这就涉及到下一个要分析的问题：3354屏幕可视高度。
屏幕可见度高度
似乎scrollTop的判断方式有所调整，部分浏览器功能被修复。不过这里测试的UC浏览器还是不正常，这涉及到浏览器的一些功能“优化”。
为了尽可能多的呈现给用户更多的页面内容，有些浏览器在上下拉动的时候会自动隐藏头部搜索框或者底部的tabbar。这很好，但是会给代码带来很多麻烦。我剪了一些图片来说明这个现象：
1.首次加载页面时：
注意这个属性的值是document . documentelement . client height=727(Mint-UI中的可视区域就是根据这个属性判断的)。本来浏览器不优化就不会有问题。
2.开始上拉时：
浏览器的页眉搜索框开始隐藏，同时window.innerHeight开始随着拖动而变化，但是Document。DocumentElement。ClientHeight始终是初始值。
状态栏更改
3.拉至顶部后：
搜索框消失，document . documentelement . client height保持不变，但window.innerHeight是屏幕的最大可见高度。
拉升结束，触发加载。
这就解释了为什么UC浏览器不行，只要把原来的逻辑调整成这样：
综上所述，以上两段内容只是对mint-ui loadmore异常上拉加载功能的研究。
演示的代码如下：https://github.com/eminoda/mint-ui-test
可见处理浏览器兼容性问题是非常困难的，需要你对相关的js api有很高的熟悉度。同时，你需要反复练习才能找到最终的答案。希望本文能为解决类似问题提供一个类似的指导，也能帮助有类似问题的同学。
关于我，一个工作在一线的前端工程师，愿意实践和分享前端相关技术。关注【前端雨爸】，欢迎评论留言，愿与你交流进步。
单击了解更多信息并查看更多相关技术文章。