为了同时支持 IndexedDB 和 MongoDB API，我抽象了一层 Service，前端调用接口就变成了： action -> Service，Service 会根据用户的选择自己决定是调用 IDB 层还是 API 层。然后用 interface 抽象了 Model 层，这里使用了策略模式，这一部分我觉得我写得算是整个项目里最秀的。
Top Level Await 的使用，还是在 Service 里，需要在实例化 Serivce 之前得到用户的选项。但是 Chrome 的 API chrome.storage.local 是异步的，如果常规思路，就是把实例化这一步放在 async 里，但是这样就无法 export 了。最后用 Top Level Await 解决，其实也就一行，加个 await 就行了！
CSS Grid 布局，之前没尝试过，这次整个项目就是用它来做的。
之前总是考虑在 content_page 监听一个 DOM 去搞定用户在点击 star 按钮的时候弹窗，但是这样一旦 Github 的 DOM 改变，我也要变！后来直接换思路，监听 star 时的 API，一旦请求这个 API，就直接弹窗，不用管 DOM 结构了！而且因为是弹窗形式，在整个 Github 网站里都通用！这个想法我自己都觉得挺惊艳的！
除了上一篇写的那两点，这次又学到了或者说稍微费了点时间做的：
action -> Service，Service 会根据用户的选择自己决定是调用 IDB 层还是 API 层。然后用 interface 抽象了 Model 层，这里使用了策略模式，这一部分我觉得我写得算是整个项目里最秀的。chrome.storage.local是异步的，如果常规思路，就是把实例化这一步放在async里，但是这样就无法export了。最后用 Top Level Await 解决，其实也就一行，加个await就行了！content_page监听一个 DOM 去搞定用户在点击 star 按钮的时候弹窗，但是这样一旦 Github 的 DOM 改变，我也要变！后来直接换思路，监听 star 时的 API，一旦请求这个 API，就直接弹窗，不用管 DOM 结构了！而且因为是弹窗形式，在整个 Github 网站里都通用！这个想法我自己都觉得挺惊艳的！还衍生出 Github-API 项目:
截至目前，GithubX 一共发布了 4 个版本，有 377 个用户。
总结一下
前两年学的概念太多，有点应接不暇，导致「学而不思则罔」，只学了概念，没有进行反思，没有深入地实践，没有 coding，就会流于表面，没有沉淀。仔细看看，这个项目是三年前我刚入职的时候就建立的，一直拖拖拉拉，到现在离职了才完成。中间经历过很多，但都不足以成为我放弃的理由，尽管中间还是放弃了，这个之后单开一篇来说。