Zeee 文 5301 kHz 2,239 字

摘要

  • Velas News上线,用于记录更新、待办事项和技术记录等。
  • Log改名为News,并划分为News、时间胶囊和Log三个子页面,均使用统一的风格重新设计,并为其添加二级导航。
  • 修复了一定概率会出现Loading chunk x failed,从而导致页面加载失败的bug。
  • 依赖库升级,包括将Webpack从v2升级为v3等。

Velas News

这是啥?

screenshot-velas-news

Velas News上线,应该算是本周Velas的大新闻了,因为没有它的上线你也看不到这篇东西。经过两天的开发和两天的测试,这个新系统终于正式被放进了Velas中。

Velas News计划用于刊登每周Velas以及Velas Camp中发生的变化、技术日志以及待办事项。一方面为接管Log的全部职责,另一方面是将以前需要在Talk发布的技术日志放到这里完成,而Talk也从此更偏向个人博客而不是技术博客。

因为使用了GitHub的api,Velas News也因此实现了留言的功能。若想对某篇文章进行留言,只需通过点击按钮跳转到相关的GitHub页面进行留言即可。留言完毕后,通过刷新页面就能看到最新的留言了。

News的版面设计参考了Firefox Nightly的博客的设计,因为我实在太喜欢这种风格了,因此在初期可能会有些雷同。同时我也进行了一些自身的思考,将Nightly的设计风格与原有的Velas 2017 Summer的设计风格相融合。在后期,我还将继续将News调整为更独立的设计。

如何办到的?

主要涉及到的技术内容有:

  • vue-cli
  • axios
  • Promise
  • sessionStorage

Velas News的工作原理为通过Axios从我的GitHub仓库中抓取Issue及留言数据,并通过marked.js将数据编译为可读的网页数据,最后由Vue呈现出来。

而News的头图实现原理是:通过一个自制的简易日期算法,从一批我精心挑选的图片中选出一张作为头图,保证了头图选取的唯一性和随机性。

这个通过Vue和GitHub的issue来搭建博客的天才想法我是偶然间从issvue了解到的,后来思考再三也发觉这个方案比较方便可行。通过这个契机,我学习了Session Storage、Promise、API等一直没机会接触的东西。Velas News也成了Velas第一个通过动态抓取数据来生成网页的实例。

相比issvue,Velas News改进了什么?

Velas News的实现方式一定程度上参照了issvue (2017-8-30) 的源码。但是,因为issvue更贴近一个“开箱即用”的博客系统,因此我得根据Velas的实际情况做一些调整和改进。

包括但不限于:

  • 将Session Storage的机制调整为刷新页面即销毁
  • 在数据获取上,移除了不必要的token参数,用于保证账号安全性
  • 针对单篇文章的数据抓取,改为了使用issue编号来获取,而不再全局抓取
  • 通过Promise的catch方法增加了一些错误处理,包括联网问题以及issue关闭问题等
  • 使用api参数来进行作者过滤,而不在前端完成
  • 评论获取的优先级放在了文章获取之后,方便发生错误时能及时响应
  • 视觉上增加了读取动画以及错误提示
  • 加入了响应式布局,以及其他一些设计改进

我十分欣赏issvue的实现思路,并认为虽然做出了改动,但是在一些实现方式上并无孰优孰劣之分。而这个博客系统仍然不完善,如没有分页处理、错误处理上仍不完善等,甚至在axios的使用上我觉得仍有待改进。让我们继续努力让这套博客方案变得更加完善吧(ง •_•)ง

逝去的Log

screenshot-velas-log

就是这样,Velas 2017 Summer又一次将一员大将——Log给砍掉了(误)。

说实话,Log是我一直以来最偏爱的模块,是Velas创建至今最长寿的页面(😂),也是News之前Velas网站里设计最精密的一个网页。通过filter把json数据编译成月份选择、日期选择以及日志列表三个部件的内容,并通过总线来联动三个部件的操作。与此同时,日期选择部件的定位实现也是在仔细思考过百度百科的定位部件实现原理之后做出来的,当时还十分有成就感。

看着从2016年5月3日直到2017年8月29日这段时间断断续续记录的这个网站的成长历程,我真的感触良多。

一直以来,我当程序员最喜欢也是最执着的一个工作就是写更新日志,因为特别有成就感、特别自豪。写代码的过程是枯燥而漫长的,如果不加以记录的话,有时会忘了自己一直以来在干什么,只会以为是在不断的修bug、加feature。而更新日志则是对程序更新历程最直接的反馈,通过这种有形的东西能提醒自己做了什么、需要做什么、是不是真的需要这样做。在编程的初期,这真是非常不错的惊醒。

而砍掉Log的契机是渐渐觉得更新日志这种方式有点太琐碎了。

特别是作为一个网站,在普通的维护期间,做的东西其实是非常单纯而不足为记的,例如一些CSS的调整或是代码优化,写下来其实根本没必要;而大一点的东西,如技术总结、代码分享则没有空间写,最后只能堆到Talk来写。渐渐会听到“我这种外行人看你的博客,却发现自己啥都看不懂”这种令我哭笑不得的话,渐渐思考着是时候做出改变了。于是趁着Velas重构这个契机,因为Log的设计风格格格不入 一咬牙将这个一直以来陪伴我的网页去掉了,改用News来收集每周值得记录的更新内容 (绝不是因为懒)

虽然不是第一次意识到前端是个快速更替的行业,但就如新Velas的副标题那样——Everything flow。(“一切皆流,无物常驻”,引用自赫拉克利特(Heraclitus)的名言。)虽然世界是不断变化的,但是如果能从这个变化中吸取经验的话,就能将一些宝贵的东西不断延续下去,从而不忘初心、不断新生。

Loading chunk x failed

自从七月中旬vue-router改为按需引入模块后,这个报错就如鬼魅一样纠缠着Velas不放。

表现为:在一定概率下,在页面A点击跳转到页面B的router-link链接时,弹出Loading chunk 1 failed (在网站结构不变时,中间的数字一般不变)报错,同时无法加载页面B。但是从页面C却能通过router-link跳转到页面B。并且在页面B加载完毕后,页面A也能跳转到页面B。

为了解决这个bug,在那一个月的时间内,我先后排除了:运营商DNS劫持、广告拦截插件误杀、Webpack打包未正确配置、Webpack v2.6.1自身的bug等种种可能性,甚至找遍了Google、Github、Stackoverflow等等网站。最后不但未有任何进展,这个问题反而随着二级导航的引入而更加频繁了。这个情形让我想起了当年被Webkit的Font Boosting所支配的恐怖……

当我快要开始怀疑人生的时候,我留意到了另一个伴随着这个报错一同出现的报错Unexpected token <。之前没太在意是因为以为这是加载不出组件的并发症,后来仔细检查才发现问题所在:这个报错是针对某JS文件的,但是在JS中是不可能出现HTML标签开头("<"开头)的东西,唯一可能就是Webpack打包时误将HTML页面当作JS文件加载了。顺着这条线索,我找到了Webpack的一个设置项:

module.exports = {
  build: {
    /* ...  */
    assetsPublicPath: '/',

对,就是最后一条"assetsPublicPath"的值,我之前是写成了相对路径"./"。当然,绝对路径"/"是Webpack的默认项。之所以会那么手贱改掉,这个锅得由某网站《使用Webpack前你要知道的十件事》一文来背。里面提到的需要将Webpack的build中"assetsPublicPath"改为相对路径,从而可以直接浏览dist文件夹下的html文件来预览网页效果。然而改成相对路径最直接的后果就是会导致chunk包的加载错误。

这次经历后,我意识到虽然前端的坑很多,但是从某种程度上自己踩坑-得到教训-改进,往往比直接听信网上不靠谱的“踩坑教训”,成本来得低得多。看似是避开了错误,却不知在无形之中埋下了更大的祸根。

尾声

不知不觉写的东西有点多😂

这是Velas News的第一篇Weekly,不知你们意见怎么样呢?欢迎通过下方留言给我提意见~~

让我们下周见吧。


© 本文文字内容著作权归Velas电波站所有。商业转载请联系站长获得授权;非商业转载请注明本文出处及文章链接,且未经站长允许不得对本文文字内容进行修改演绎。