又被坑了之自动跳转

96
半生不熟_
2018.11.30 18:02* 字数 1421

如果选择用一段话来概括这篇文章,那可能是这样的。

有时候做一个东西的时候潜意识地觉得自己没做过,不熟悉,然后就立马打开 Chrome 去搜,然而不巧网上的这方面的答案都随波逐流走偏了,看似完美的实现了,实际背后埋藏着很大的坑,但匆匆一看,这就是你想要的,这时候,你的思路也就潜移默化地被带偏了。

但当你泡好了茶,认真测试的时候,才发现,我靠,怎么会有个 Bug,一阵抓狂之后就开始想着怎么填上这个坑,于是一套自己认为可以完美修复并且对用户友好的方案就出来了,但当你再次准备好一切,正想怎么去实现它的时候,无意间随手又试了试一个自己的想法,刹那间,什么都不一样了,就多想了那么一一点点 才发现自己很容易就能解决那个问题,根本不用什么自己觉得复杂而且对用户友好的设计,最后就剩吐槽网上的答案了。

想如果你还感兴趣,那就继续滑吧。
想必你应该对这样一个功能并不陌生。

自动跳转下一个input

可能你会想说这个问题不是很简单吗,没错,我当时也这样想,实际做完后才发现,它是真的简单。

大体的思路:对于自动 focus on 下一个输入框,监听 input 的事件,在用户输入满足校验条件以及限定的位数的时候,获取下一个应该给聚焦的元素,然后调用 focus 方法。

然后对于这个需要监听的 input 事件,想都没想,就打开 Chrome了,连续看了四五六七八个解决方案,一致地推荐 onKayUp 是个完美的解决方案。

测试完毕,欣喜,提交。

然鹅,当我输完第三个,我想直接回去修改上一个,才发现 Shift tab 根本回不去,如果想硬回,要不上鼠标,要不同时按个 Shift Tab Space 键。

像这样:

Shift Tab issue

然后第一反应是去网上试了五六七八个推荐用法的 Demo,原来都有这个问题,What?这些人都不修的吗,终于找到一个Shift Tab 可以回去的,看了下描述,是用了一个 Toggle 来控制 自动跳转的功能会不会被启用。

仔细又测了一波,发现 Tab 的时候也有同样道理的问题,如果我现在从第一个填到了最后一个,这时候发现都填的不对,但我就是想从第一个iput 开始修改,这时候 Shift Tab 是回不去的,无奈,用鼠标点击了第一个input,修改完后,心想跳到第二个应该就可以再改了,然鹅,它直接给我跳转到了第三个。

我在想,幸好,我这只有三个 input需要实现自动跳转,如果有七八九十个,那还不得给用户表演个一系列跳转动画?

然后,就在这个坑里挣扎,想着要怎么跳出去呢,是不是需要监听用户使用了 Shift 还是 Shift Tab 还是鼠标呀,你根本不知道用户是怎么样在你的页面点点点一通的。

冷静下,仔细思考下怎么样才能尽可能地让用户收益于这个自动跳转功能,还不会被它带来的副作用 block 呢。

于是,就有了这样一张图,还和其他同事讨论了一下这方案,都觉得可行,虽然看着有点略复杂,但这个问题百分百是要修的。


图片发自简书App

当做好所有准备,开始按这样实现的时候。

想了一个问题,onKeyUp才是罪魁祸首呀,当Shift Tab 按下的时候,就是因为触发了 keyUp 事件,所有根本跳不回去。我为什么不用 onChange?

冷静了1分钟,我为什么不用 onChange,?竟半天想不出答案。

实锤了一波,简直完美。这里有 Demo,感兴趣可以点一点,哈哈。

还想了想这样用是不是有什么别的坑,因为百分之九十九的答案都是 onKeyUp。 但我想说,真的是不对的,要不是账号有经验限制,真想每个都评论一遍问下作者这个问题。

其实一开始真的觉得很浪费时间,自己干嘛不多想那么一下,如果一开始没有去搜,直接用了 onChange,是不是就根本没有这个问题,但换了个思路想,如果没有搜,也不会知道网上的这些一模一样所谓正确的答案原来都是有问题的,那也就不会有坐在这里一字一句地把件事情记录下来,让更多的人意识到这个问题,也提醒自己以后不要犯类似的错误。

也许,这就是生活吧。
少走了弯路,也就错过了风景。

web前端
Web note ad 1