下拉框搜索

最近頁面中需要一個下拉框，并且支持搜索功能（搜索選項文本和拼音），這是一個挺普通的小功能，代碼如下：

request.ts 先準備一些假的下拉框數據，并模擬請求：

圖片

Index.vue 中進行請求，并渲染下拉框，配置一些屬性，支持搜索選項文本：

圖片

可以看到實現了搜索文本，但是產品說還得支持搜索拼音呢~可以看到當前是不支持搜索拼音的。

圖片

拼音搜索

拼音搜索其實也不難，用一些庫即可，比如 pinyin-pro。

pnpm i pinyin-pro

我可以使用 pinyin-pro 這個庫，在獲取數據的時候為每一項的文本進行拼音翻譯，并放到字段 keywords 中。

圖片

現在可以看到每一項都有一個 keywords 字段，里面存了每一項的文本和拼音。

圖片

接著，在頁面中配置一下 Select 的搜索過濾函數。

圖片

現在就支持了文本搜索和拼音搜索了。

圖片

多個下拉框拼音搜索

上面例子是只有一個，那如果有多個下拉框呢？比如有兩個下拉框，我準備了兩個下拉框的假數據。

圖片

接著在頁面中展示兩個下拉框：

圖片

可以看到兩個下拉框的拼音數據耗時情況，其實當時頁面上不止兩個下拉框，大概有十幾個下拉框，且數據都很巨大，如果每一個下拉框都要接近200ms的耗時的話，那用戶體驗會很不好。

圖片

性能優化

根據觀察，我發現我這個頁面的十幾個下拉框其實都有很多下拉項是相同的，這意味著，有一些項存在重復翻譯的問題。

就比如這個“放米”，options1翻譯過一遍了，options2還翻譯一遍，這就導致了性能損耗。

圖片

所以其實可以使用緩存來進行優化，思路就是：

1、準備一個對象，key 是文本，value 是拼音

2、每次翻譯的時候

先檢測對象里是否能匹配到。

能匹配到直接用，不能匹配到才調用 pinyin-pro 進行翻譯。

圖片

這樣的話，能避免文本的重復翻譯，從而提升性能，由于 options2 有很多跟 options1 相同的項，所以 options2 很多項的翻譯都是直接取緩存的，數據處理的速度大大提升！

圖片

其實這種方式也是有局限性的，如果每一個 options 的數據重合度都不高的話，那么這種優化方式也就沒啥意義了

所以最好的方式還是叫后端翻譯好拼音，傳給前端。

類似的場景

其實不止是上面舉的例子，還有其他項目中類似的場景，需要用到這種優化方式，比如：復雜的翻譯、復雜的數據處理。

例子終究是例子，重要的是能舉一反三。