本篇不是教程，类似于开发日记，记录一下在编写友链朋友圈前端方案中遇到的问题和积攒的经验。顺便聊聊我的开发习惯。

最开始答应@贰猹写友链朋友圈3.0前端方案时，我正好刚刚开始沉迷原神。啊呀，说起来当初帮@冰老师写友链朋友圈1.0方案的时候我正好被贰猹拉去沉迷MC,该说是因果循环吗？2333。

首先来说下API的事情，最初版本的友链朋友圈API可以说是冰老师拍脑袋想出来的，不管从代码上还是呈现效果上都显得较为粗糙，这个和冰老师本身不是工科出身有关系，不过也正因如此，不得不让我在此佩服冰老师的强大。他总能在沉寂一段时间后学到新的东西，然后给大家一个惊喜。而我的思维却已经显得有些僵化。至少我是绝对不会突破静态博客的局限，去考虑一个将各个友链博客联动起来的友链朋友圈的。

跑题了，继续说友链朋友圈API，初版的API没有具体的对象名，与其说是个json，不如说是个字符串，冰老师把需要的信息爬取以后，在前端对冗长的数据进行处理，所以初版的友链朋友圈会显得较慢。3.0版本，友链的具体内容处理都被贰猹放在后端解决，实现了前后端分离，且高内聚低耦合，是非常理想的开发结构。新的友链API，直接可以通过对象访问，获取到友链基本信息和文章基本信息。

初版的API是没有更新时间的，只有创建时间，或者说它只有一个时间（可能是更新的可能是创建的），而大部分同学没有自定义update项的习惯，加上github action会清空过去的更新时间，导致所有更新时间一致。这也使得旧版的友链朋友圈一度出现一个人刷屏霸榜的现象，不得不说，观感很差（虽然那时候霸榜最多的就是我自己，以至于被冰老师改了规则制裁）。新版则是通过对友链文章信息进行重新排序（这里贰猹调整了爬取规则，可以同时获取创建时间和更新时间），可以通过前端交互实现按照更新时间排序或者按照创建时间排序。非常的人性化。

朋友圈CDN引入方案出来的时候，我也同步写了友链朋友圈的NPM插件。这个CDN引入方案的更多按钮逻辑也是有误的，冰老师是通过一个变量递增每次整体重新加载一遍朋友圈，而3.0前端方案中，我通过dom操作先读取当前有的文章数，再从这篇的下一篇开始增量加载。节省反复加载的时间和资源。同时，3.0方案中，用本地存储先将爬取到的信息存起来，等切到朋友圈页面时再从本地读取。加上将爬取函数和页面加载函数进行分割引入，爬取函数全局引入，分割函数指定页面局部引入，访问其他页面时就完成了友链朋友圈的爬取，某种意义上实现了真正的预加载。

友链朋友圈1.0-2.0友链朋友圈3.0
API返回json结构含义不清晰，可读性差API返回json结构清晰，信息罗列规范易读
前端方案全局重载，前端计算，耗时较长后端计算，前端直接读取调用，秒加载
全局重载，反复加载重复资源增量更新，能够有效节省资源
全局引入，无友链页面也会执行，还易报错分割引入，全局预加载信息，指定页面加载内容

至于前端的UI设计反而是最不值得称道的。我出于个人执念，一如既往的采用了SAO UI风格的设计，将基本信息做成了计量条，配色也是SAO的白灰主色调。dom结构和css均已开源，想必以后洪哥肯定是会有一款配色方案的。至于更多内容就得看我有没有时间了。

在开发过程中，我一开始是想到用PUG语法来处理循环输出友链文章的结构，但是这样一来就会在编译生成过程中固化友链朋友圈信息，不符合它的现势性要求，而在1.0方案中，冰老师使用到了vue的循环结构来输出，后来的CDN方案中改用了原生js语法，3.0方案最终也是使用的原生js，得益于贰猹重写过的API，编写起来十分顺滑（在这之前我一直推阻不想写的一部分原因就是这个循环结构太麻烦了，但是真到上手的时候却很容易就克服了这个难关，再次表扬贰猹的API，这TM的才叫json啊！）。有兴趣写API相关的插件的同学可以将3.0的前端方案作为案例参考，爬取到本地存储，再从本地读取的“预加载”模式，相信能启发很多被API速度或者Pjax重载困扰的开发者。源码可以直接查看插件仓库：