為什麼#
openlayers 的 API 文件內容非常好，但使用起來卻有些困難。
一般查詢 API 的方式有以下兩種：
- 搜尋引擎 👉 openlayers + 關鍵字 👉 打開指定連結
- 打開 API 文件頁面 👉 搜尋關鍵字 👉 通過搜尋結果到達指定結果
OL 搜尋 1#
OL 搜尋是一款瀏覽器擴展（目前只上架了 Edge add-ons2），可以通過瀏覽器地址欄快速搜索 openlayers API，步驟如下：
- control+L 或者 cmd+L 進入搜尋欄。
- 輸入
ol關鍵字，tab 或者 space 進入 OL 搜尋。 - 輸入目標 API（方法、成員變量、觸發器等）的關鍵字，選擇指定連結直達。
實現#
主要分三步：
解析 API 文件#
https://openlayers.org/en/latest/apidoc/navigation.tmpl.html
文件的導航欄部分嵌入了一個 HTML，來自上面的地址。
這裡本來有兩個思路。
一是通過修改 openlayers 自己的 api build 的腳本生成一組與上述 HTML 內容一致的 JSON 格式的 API 文件信息。
但考慮到兩點：
- 後期維護問題，如果這麼做，每個小版本更新需要重新更新插件。
- 插件體積變大。
另一種是直接解析上面的 HTML 的導航信息文件，這裡遇到了問題，因為在瀏覽器的擴展中，backgroud.js裡無法訪問DOMParser對象，這裡走了彎路，最開始曲線救國，通過popup（點擊擴展圖標顯示的小彈窗）加載數據。這種方式缺點很明顯，用戶安裝完擴展後無法直接使用，需要點擊擴展圖標等待索引文件初始化後才能使用。之後找到了一個純javascript的 DOM 解析庫，才解決了該問題。
模糊搜索#
最開始的時候採用硬搜索，自己使用起來都不滿意，因為打字偶爾的 typo 不可避免，因此模糊搜索應該是剛需。
這裡參考了mdn-search 的做法，引入了 fuse.js 。也做了一些多關鍵字的增強。
比如在搜索 readFeatures 這個方法的時候，各種格式例如 EsriJSON、KML、WKT 等都有 readFeatures 方法，而默認搜索結果 WKT 在後面，假如我想找 WKT 的 readFeatures 的話就會影響體驗。
通過 fuse.js 的 search.$or，實現了多關鍵字的複合搜索。
這樣只需要輸入 readFeatures wkt 就可以將包含 WKT 的結果提到第一個候選。
幹掉默認推薦#
在監聽地址欄 omnibox 內容變化事件的回調函數中，瀏覽器默認會在你給的推薦結果前面默認加一條默認推薦，其內容是你鍵入的內容，指向的地址是你擴展的地址加上該內容。默認行為即 File not found。
這部分思路來自rust-search-extension ，首先根據用戶的鍵入內容結合搜索結果，將默認推薦設置為原本的第二條結果（真正搜索結果的第一順位），之後在用戶回車後判斷該選項是否是默認建議，如果是，則指向真正搜索結果的第一順位的地址。
最後#
希望該工具給重度使用 openlayers API 文件的各位同仁帶來幫助。