陈不易

為什麼#

openlayers 的 API 文檔內容是極好的，然而使用起來卻一言難盡。

一般的查 api 的方式有以下兩種：

• 搜索引擎 👉 openlayers + 關鍵字 👉 打開指定鏈接
• 打開 api doc 頁面 👉 搜索關鍵字 👉 通過搜索結果到達指定結果

OL Search ¹#

OL Search 是一款瀏覽器拓展（目前只上架了 Edge add-ons²），可以通過瀏覽器地址欄快捷搜索 openlayers api，步驟如下：

1. control+L 或者 cmd+L 進入搜索欄。
2. 輸入ol關鍵字，tab 或者 space 進入 OL Search。
3. 輸入目標 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 doc 的各位同仁帶來幫助。