又被坑了之自动跳转

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

有时候做一个东西的时候潜意识地觉得自己没做过，不熟悉，然后就立马打开 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 呢。

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

又被坑了之自动跳转

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

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

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

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

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

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

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