摘要：于是，又接着搜索，发现了这个仓库。在正式进入开发之前，我们再来体验下的调用。再发几次请求会发现，一直在持续减少。。。其中明确提到，它会根据来限制调用的频次。对于未授权的访问，一小时最多次而授权的访问，一小时最多次。
1. 前言
这天，在逛github（就是划水）的时候，突然想看看某个仓库的star走势，但是在star列表中翻了半天愣是没找到相应的功能。于是乎，谷歌一搜，发现有个叫Star History的谷歌插件，然而竟然要收费。。。
于是，又接着搜索，发现了这个仓库。好巧的是，这个仓库就是那个插件的源码。稍微瞅了下源码，感觉我也能行？
由于之前就想学学怎么写chrome插件，本着学习的态度和好奇心驱使（都是划水，没有什么不同），于是也做了一个可以查看仓库Star趋势的插件。效果如下：
2. 准备工作 2.1 chrome插件简单入门由于也是第一次写Chrome插件，作为小白，就先搜搜大家都是怎么写chrome插件的吧。果然，一搜一大堆。。。不过，最终还是选择了官方文档，毕竟是第一手资料，虽然是英文，但写得还算通俗易懂，阅读起来没啥问题。
这里推荐看Getting Started，非常友好，一步步教你完成一个最简单的修改网页背景颜色的Chrome插件。跟着教程完成之后你就会发现，原来Chrome插件就像完成一个web项目一样。
manifest.json是项目的配置文件（类似于package.json），插件所需要的一些能力（例如Storage）就在这个文件中声明。剩下的工作，无非就是根据Chrome插件提供的API实现你想要的功能即可。
我们来看下要创建的项目目录和manifest.json配置文件：
├── README.md ├── dist │ └── bundle.js ├── images │ ├── trending128.png │ ├── trending16.png │ ├── trending32.png │ └── trending48.png ├── manifest.json ├── package.json ├── src │ └── injected.js └── webpack.config.js
{
"name": "Github-Star-Trend",
"version": "1.0",
"manifest_version": 2,
"description": "Generates a star trend graph for a github repository",
"icons": {
"16": "images/trending16.png",
"32": "images/trending32.png",
"48": "images/trending48.png",
"128": "images/trending128.png"
},
"content_scripts": [
{
"matches": ["https://github.com/*"],
"js": ["dist/bundle.js"]
}
]
}
这里需要解释一点，根据最一开始我们看到的效果图，可以发现我们正在浏览的页面上多了一个Star Trend按钮。所以我们要完成的插件需要能够往页面注入一个按钮，而这正是通过manifest.json中的content_scripts字段实现的。它允许我们往matches字段匹配的网页中注入js字段中的脚本文件。
因此，上面的配置意思很简单，就是在匹配到url是https://github.com/* 的网页时，注入我们dist目录下的bundle.js文件。而bundle.js其实是我们为了在项目中用上ES6而采用webpack编译得到的，源码就是src/injected.js。接下来的工作就是在我们的src目录下开发就行了（都是写js，没什么不同）。
2.2 Github API在正式进入开发之前，我们再来体验下Github的API调用。官方文档在这儿，概览看完之后，经过一番搜索，终于找到我们的主角Starring APi。
根据这个API，我们可以拿到某个仓库的Star列表。仔细看文档，能够看到有这么一条：
You can also find out when stars were created by passing the following custom media type via the Accept header:
Accept: application/vnd.github.v3.star+json
太棒了，这不正是我们所需的star时间吗？赶紧打开postman测试一把：
果然，我们顺利拿到了star仓库的时间。不过这里有一个问题，这个请求每次返回的个数只有30条，也就是说假如像react这样十几万star的仓库岂不是要请求3k+次。。。而且，还有另外一个重要的问题，那就是Github API对调用的频率也有限制。。。
在上面的图片中，Response Header中告诉我们limit是60次，remaning还有59次。再发几次请求会发现，remaning一直在持续减少。。。在翻阅了一番文档之后，我找到了这个。
For API requests using Basic Authentication or OAuth, you can make up to 5000 requests per hour. For unauthenticated requests, the rate limit allows for up to 60 requests per hour. Unauthenticated requests are associated with the originating IP address, and not the user making requests.
其中明确提到，它会根据ip来限制API调用的频次。对于未授权的访问，一小时最多60次；而授权的访问，一小时最多5000次。所以，为了尽可能避免的访问频次带来的问题，我们在请求中需要带上access_token。有关access_token，你可以在这里申请。
3. 开工经过前期的一番调研，事实证明想法确实可以实现。我们再来简单理下思路：
根据页面的dom结构，找到注入Star Trend按钮的位置（injected.js）
给Star Trend按钮绑定点击事件，发起获取Star时间的请求，收集数据（fetchHistoryData.js）
根据返回的数据，利用echart.js绘制趋势图（createChart.js）
3.1 injected.js利用chrome的元素审查功能，我们可以很轻松地找到要注入按钮的位置，并给它绑定上相应的点击事件。
/**
* star趋势按钮点击事件
*/
function onClickStarTrend() {
// todo: 发起请求
console.log("u click star trend");
}
/**
* 创建star趋势按钮
*/
const createStarTrendBtn = () => {
const starTrendBtn = document.createElement("button");
starTrendBtn.setAttribute("class", "btn btn-sm");
starTrendBtn.innerHTML = `Star Trend`;
starTrendBtn.addEventListener("click", onClickStarTrend);
return starTrendBtn;
};
/**
* 注入star趋势按钮
*/
const injectStarTrendBtn = () => {
var newNode = document.createElement("li");
newNode.appendChild(createStarTrendBtn());
var firstBtn = document.querySelector(".pagehead-actions > li");
if(firstBtn && firstBtn.parentNode) {
firstBtn.parentNode.insertBefore(newNode, firstBtn);
}
};
(function run() {
injectStarTrendBtn();
}());
如果你已经安装了本地的这个插件，这个时候刷新页面你会发现多了一个Star Trend的按钮，点击的时候会在控制台打印出u click star trend的字样。
3.2 fetchHistoryData.js获取数据首先要解决的就是构造请求url，根据文档所示，我们需要当前的仓库信息。这个倒是简单，直接上正则从当前的location.href中匹配出来即可：
const repoRegRet = location.href.match(/https?://github.com/([^/]+/[^/]+)/?.*/);
然后是请求参数：
const requestConfig = {headers: {Accept: "application/vnd.github.v3.star+json"}};
这样，我们就可以用axios发起一次请求：
const url = `https://api.github.com/repos/${repoRegRet[1]}/stargazers`;
axios.get(url, requestConfig).then(firstResponse => console.log(firstResponse));
查看log，我们成功地获取到了一个仓库第一页的star列表。不过，这里有几个问题需要解决：
如何获取第2页，第3页，第N页的star列表？
如何知道一个仓库有多少页star（即N是多少）？
当一个仓库的star数多到要发送几百次，甚至上千次请求时，如何决策？
第一个问题很好解决，在上面的url后面，跟上?page=n就表示请求第n页的star数据。
第二个问题有两种解法。一种是知道该仓库有多少star，然后除以30（一页返回30条数据）就可以知道有多少页了；还有一种方法其实API文档已经告诉我们了，第一次请求返回的数据已经告诉我们有多少页了，只不过这个数据被放在了response的headers中。其中有一个link字段：
