事情是這樣式兒滴~~~~
在IM工具、Wiki文檔中我們經常使用
@
符号來做提及人、提及文檔的功能,最近胡哥就是在做這個業務需求的時候被
@
這個符号坑慘了。
PM想要的效果大概是這樣:當使用者輸入
@
後,能夠響應一系列的推薦結果。
![](https://img.laitimes.com/img/9ZDMuAjOiMmIsIjOiQnIsICN4ETMfdHLkVGepZ2XtxSZ6l2clJ3LcBnYldHL0FWby9mZvwVPrdEZwZ1Rh5WNXp1bwNjW1ZUba9VZwlHdsAjMfd3bkFGazxCMx8VesATMfhHLlN3XnxCMz8FdsYkRGZkRG9lcvx2bjxSa2EWNhJTW1AlUxEFeVRUUfRHelRHL2EzXlpXazxyayFWbyVGdhd3LcV2Zh1Wa9M3clN2byBXLzN3btg3PwJWZ35iM4QDO5MTYjdDOklTOjFGZyYzX5IDMwADMzIzLcdDMyIDMy8CXn9Gbi9CXzV2Zh1WavwVbvNmLvR3YxUjLyM3Lc9CX6MHc0RHaiojIsJye.webp)
溝通完需求,PM習慣性的描述了老闆催的緊,要排期,我在臉上努力擠出一副苦大仇深的樣子,不情不願的說道“我争取1天完成吧”,内心則甚是竊喜:“就這功能,監聽個keydown事件,判斷是@符号不就完了!半天時間足夠了,還能摸魚半天,哈哈哈~”
TIPS: 這裡後端接口是已經完備的,是以沒什麼阻塞需求的地方。
整活,提測~
項目是vue環境下,沒别的,監聽鍵盤事件,開始整活~
<template>
<input type="text" @keyup="atHandler" />
</template>
<script>
export default {
methods: {
atHandler (e) {
// 使用e.keyCode來判斷是否是@符号 ===> 50
// 或者使用ascii碼值 64表示@符号,使用charCodeAt()轉為Unicode字元,ASCII碼
switch (e.keyCode) {
case 50:
if (e.key === '@') {
// balabala...
console.log('你按下了@符号');
// 處理業務邏輯
// 喚起提及人浮窗
}
break;
default:
break;
}
}
}
}
</script>
本地測試沒問題,Call測試同學,提測,走你,開始
摸魚~
。
附ASCII碼表:
測試 - 天生具備BUG體質
整摸魚開心,忽然看到IM上,測試同學在Call,說是有BUG!輸入
@
符号後,無法喚起提及人浮窗!瞬間就懵逼了!
和測試一頓拉扯,最後測試同學送出了一份視訊,明明白白有這個現象,确實沒有喚起浮窗!
又找了些其他同學的電腦,進行了相同的測試,發現都沒有問題。而且這段代碼邏輯确實非常簡單呀,既然有能喚起的,說明邏輯是正确的,但是在測試同學的電腦上是100%複現的,對她來說這個功能就是100%不可用的。
本着使用者體驗之上原則,在測試同學電腦上專門debug了一下,列印了
@
的
e.keyCode
竟然不是
50
,而且通過
charCodeAt
轉換出來的ASCII碼也不是
64
!!!。
每個字元都會對應相應固定的ASCII碼,Unicode字元呀,怎麼還有不一緻的時候呢?!
這不應該呀,這就相當于
1+1
忽然間不等于
2
了。
這真是離了個大譜!!!
簡直挑戰了一個前端開發的底線了有沒有~~~
坑爹的輸入法
當問題出現的時候,沒有任何一個環節是無辜的!
複現該測試同學的所有環境:
-
windows
電腦
印象中也沒有關于windows電腦會有這個相容性呀!本着甯殺錯,不放過原則。對照組實驗搞起來!
找了另外2台windows電腦,都沒有複現這個BUG!
說明了Windows系統沒有關系呀!
這個時候,稍稍感覺今天被針對了,什麼莫名其妙的BUG!
-
輸入的@符号會有不同嗎?看起來是一樣的呀!
感謝偉大的“實事求是”精神,測試出BUG的同學使用的是
,其他Windows電腦使用的是QQ拼音輸入法
搜狗拼音輸入法
,現在輸入法成了新的實驗變量。
快速的安裝了
,果然,BUG必現!QQ拼音輸入法
為啥這個問題,這麼不好找呢。是因為QQ拼音輸入法不支援在Mac上用,相對搜狗比較小衆些。
- 此時此刻,可以看到輸入的都是
字元,肉眼無法分辨,但是從根本上來說,這個@
輸入的字元絕對不是标準的QQ拼音輸入法
對應的Unicode字元。@
如果有搞測試輸入法的同學,一定不吝賜教,給解釋下!
問題原因定位了,既然沒有辦法讓所有的使用者都不用QQ拼音輸入法,即使能,也可能存在其他輸入法引起這個問題!隻能做相容性處理了,為了安全起見,讓測試的同學安裝測試了市面上常見的輸入法!
以下是常見輸入法在不同系統輸出@字元的keyCode值和ASCII碼值
輸入法名稱 | 系統 | key值 | keyCode值 | ASCII碼值 |
ABC輸入法 | MAC | @ | 50 | 64 |
簡體拼音輸入法 | MAC | @ | 50 | 64 |
搜狗輸入法 | MAC | @ | 50 | 64 |
百度拼音輸入法 | MAC | @ | 50 | 64 |
百度拼音輸入法 | Windows | Process | 229 | 66 |
微軟拼音輸入法 | MAC | @ | 50 | 64 |
微軟拼音輸入法 | MAC | @ | 50 | 64 |
QQ拼音輸入法 | Windows | Process | 229 | 66 |
訊飛輸入法 | Windows | Process | 229 | 66 |
歡迎大家補充
相容方案處理
在使用keyCode監聽時,除了
50
之外,同時監聽
229
,保證各個輸入法下都能正确響應事件。
export default {
methods: {
atHandler (e) {
switch (e.keyCode) {
case 50:
case 229:
if (e.key === '@' || e.key === 'Process') {
// balabala...
// 處理業務邏輯
// 喚起提及人浮窗
}
break;
default:
break;
}
}
}
}
送出測試,完美通過!繼續摸魚!
快來測試下你的輸入法正不正經!!!
在排查BUG的過程中,非常有意思的一個體驗!我也寫了個Demo程式來測一測你的輸入法是不是正經輸入法!希望你再遇到相同需求的時候,不會手忙腳亂!
碼上掘金位址:
代碼片段
CodeSandBox位址:不正經位址傳送門
上效果圖: