前文 对于单页应用中如何监听 URL 变化的思考 说到我在开发 chrome 扩展 GitHub Remarks 中遇到的一个问题，本文来聊聊开发这个扩展的前后心路历程。
为什么开发这个扩展？前文说到：
开发这个扩展的原因是我在 GitHub 中所 star 的项目实在太多了（截止目前 671 个），有的项目过个几天回来看就忘了为什么 star 了，有的*想找的时候发现忘记叫什么了，这么多一个个找实在浪费时间。于是我一直在想有这么个工具，可以自定义对 GitHub 中的项目进行备注，然后可以根据备注进行搜索，于是便有了这个扩展。
综上，这个扩展有两个功能：
- 对 repo 进行备注（可以在 repo 详情页或者自己的 stars 列表页）
- 根据备注对 repo 进行搜索（stars 列表页）
一开始我的设想中是有另外一个重要功能的，那就是 stars 分类。也就是像浏览器书签一样，设置 tags 进行分类。很显然，市面上的 stars 管理工具都有这个功能（比如 OhMyStar），不过很多是仅仅有这个功能。
但是，从一开始，我就将其定位为一个浏览器扩展，而不是第三方工具（web 或者 app，本文的基于 web 专指基于第三方的 web 网站），因为我个人平时也就网页版的 GitHub 用的多，如果需要打开第三方，无形中就增加了使用成本。
搜索了下，stars 管理的 chrome 扩展也确实有，比如 Github Stars Manager 以及 GitHub Stars Tagger。它们的思路都是类似，根据 GitHub 提供的 API 获取所 stars 的项目，然后和保存的 tags 数据进行匹配（可以用 chrome.storage.sync API），然后再把 dom 画上去。这里最关键的一步就是获取所 stars 的项目，因为 API 所限制，一次请求只能获取 100 条数据，所以需要多次请求，这个时间消耗非常大，再者，因为浏览器扩展是基于页面，也就意味着每次刷新，每次进入新的页面，都需要重新进行请求操作，而不是像基于 web 和 app 的管理工具一样能对数据进行缓存。
基于此考虑，我放弃了对 stars 进行分组（标记）的功能。我也曾考虑过将数据进行缓存，但是因为基于页面，缓存周期很难把控（不像基于 web 或者 app 可以自主进行刷新），遂放弃，不得不说是一个遗憾。
而另外一个遗憾是，由于 chrome.storage.sync API 对于储存数据大小的限制，使我不得不改用 chrome.storage.local API，理论上说起的作用和 localStorage 类似。
基于这两个遗憾，个人觉得这个扩展的使用也是十分受限的。首先需要是 GitHub stars 的重度用户，然后要对 repo 备注有需求，方便以后的查找，因为很多人对于 star 对于收藏的东西是不会去看第二次的。再者，最好只在一台电脑上工作，因为数据不能同步的问题。
总之，这个扩展很好的满足了我自己的需求，接下去如果有需要，会考虑下数据导入导出的功能。