陈不易

为什么#

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 的各位同仁带来帮助。