FastClick遇到的坑及解决办法

最近产品妹子提出了一个体验issue —— 用 iOS 在手Q阅读书友交流区发表书评时，光标点击总是不好定位到正确的位置：

如上图，具体表现是较快点击时，光标总会跳到 textarea 内容的尾部。只有当点击停留时间较久一点（比如超过150ms）才能把光标正常定位到正确的位置。

一开始我以为是 iOS 原生的交互问题没太在意，但后来发现访问某些页面又是没有这种奇怪体验的。

然后怀疑是否 JS 注册了某些事件导致的问题，于是试着把业务模块移除了再跑一遍，发现问题照旧。

于是只好继续做排除法，把页面上的一些库一点点移掉再运行页面，结果发现捣乱的小鬼果然是嫌疑最大的 Fastclick。

然后呢，我试着按API所说，给 textarea 加上一个名为“needsclick”的类名，希望能绕过 fastclick 的处理直接走原生点击事件，结果讶异地发现屁用没有。。。

对此感谢后面我们小组的 kindeng 童鞋帮忙研究了下并提供了解决方案，不过我还想进一步研究到底是什么原因导致了这个坑、Fastclick 对我的页面做了神马~

所以昨晚花了点时间一口气把源码都蹂躏了一遍。

这会是一篇很长的文章，但会是注释非常详尽的剖析文。

文章带分析的源码我也挂在我的 github 仓库上了，有兴趣的童鞋可以去下载来看。

闲话不多说，咱们开始深入 FastClick 源码阵营。

我们知道，注册一个 FastClick 事件非常简单，它是这样的：

所以我们从这里着手，打开源码看下 FastClick .attach 方法：

这里返回了一个 FastClick 实例，所以咱们拉到前面看看 FastClick 构造函数：

在初始通过 FastClick.notNeeded 方法判断是否需要做后续的相关处理：

我们看下这个 FastClick.notNeeded 都做了哪些判断：

基本上都是一些能禁用 300ms 时延的浏览器嗅探，它们都没必要使用 Fastclick，所以会返回 true 回构造函数停止下一步执行。

由于安卓手Q的 ua 会被匹配到 /Chrome\/([0-9]+)/，故带有 'user-scalable=no' meta 标签的安卓手Q页会被 FastClick 视为无需处理页。

这也是为何在安卓手Q里没有开头提及问题的原因。

我们继续看构造函数，它直接给 layer（即body）添加了click、touchstart、touchmove、touchend、touchcancel（若是安卓还有 mouseover、mousedown、mouseup）事件监听：

注意在这段代码上面还利用了 bind 方法做了处理，这些事件回调中的 this 都会变成 Fastclick 实例上下文。

另外还得留意，onclick 事件以及安卓的额外处理部分都是走的捕获监听。

咱们分别看看这些事件回调分别都做了什么。

1. this.onTouchStart

顺道看下这里的 this.updateScrollParent：

另外要注意的是，在 onTouchStart 里被标记为 true 的 this.trackingClick 属性，都会在其它事件回调（比如 ontouchmove ）的开头做检测，如果没被赋值过，则直接忽略：

当然在 ontouchend 事件里会把它重置为 false。

2. this.onTouchMove

这段代码量好少：

看下这里用到的 this.touchHasMoved 原型方法：

3. onTouchEnd

这段比较长，我们主要看这段：

其中 this.needsFocus 用于判断给定元素是否需要通过合成click事件来模拟聚焦：

另外这段说明了为何稍微久按一点（超过100ms）textarea ，我们是可以把光标定位在正确的地方（会绕过后面调用 this.focus 的方法）：

接着咱们看看这两行很重要的代码：

所涉及的两个原型方法分别为：

⑴ this.focus

注意，我们点击 textarea 时调用了该方法，它通过 targetElement.setSelectionRange(length, length) 决定了光标的位置在内容的尾部（但注意，这时候还没聚焦！！！）。

⑵ this.sendClick

真正让 textarea 聚焦的是这个方法，它合成了一个 click 方法立刻在textarea元素上触发导致聚焦：

经过这么一折腾，咱们轻点 textarea 后，光标就自然定位到其内容尾部去了。但是这里有个问题——排在 touchend 后的 focus 事件为啥没被触发呢？

如果 focus 事件能被触发的话，那肯定能重新定位光标到正确的位置呀。

咱们看下面这段：

通过 preventDefault 的阻挡，textarea 自然再也无法拥抱其 focus 宝宝了~

于是乎，我们在这里做个改动就能修复这个问题：

或者：

这里要吐槽下的是，Fastclick 把 this.needsClick 放到了 ontouchEnd 末尾去执行，才导致前面说的加上了“needsclick”类名也无效的问题。

虽然问题原因找到也解决了，但咱们还是继续看剩下的部分吧。

4. onMouse 和 onClick

常规需要阻断点击事件的操作，我们在 touch 监听事件回调中已经做了处理，这里主要是针对那些 touch 过程（有些设备甚至可能并没有touch事件触发）没有禁用默认事件的 event 做进一步处理，从而决定是否触发原生的 click 事件（如果禁止是在 onMouse 方法里做的处理）。

小结

1. 在 fastclick 源码的 addEventListener 回调事件中有很多的 return false/true。它们其实主要用于绕过后面的脚本逻辑，并没有其它意义（它是不会阻止默认事件的）。

所以千万别把 jQuery 事件、或者 DOM0 级事件回调中的 return false 概念，跟 addEventListener 的混在一起了。

2. fastclick 的源码其实很简单，有很大部分不外乎对一些怪异行为做 hack，其核心理念不外乎是——捕获 target 事件，判断 target 是要解决点透问题的元素，就合成一个 click 事件在 target 上触发，同时通过 preventDefault 禁用默认事件。

3. fastclick 虽好，但也有一些坑，还是得按需求对其修改，那么了解其源码还是很有必要的。

相关推荐：

js原生实现FastClick事件的实例

以上就是FastClick遇到的坑及解决办法的详细内容，更多请关注Gxl网其它相关文章！