日志系统施工进度

发布于2018-12-06

经过断断续续地研究与施工，和上次日志时候相比，日志系统已经比较完善了，虽然还有一些坑没有补上，但也已经正式上线运行。目前 kagami.me 会跳转到 kagami.moe，然后 blog.kagami.moe 还运行着旧系统，方便进行内容对比。

Netlify

日志最后选择部署在 Netlify 上。Netlify 在目前的我看来简直是完美，可以免费使用，支持多个自定义域名，支持重定向配置，有 CDN，与 GitHub 有良好的集成，可以预览 PR 分支……等等，完全满足了静态站点托管的各种需求。如果不是因为操作有点繁琐，而且现在的 Hurricane Electric DNS 也挺方便，我甚至想把 DNS 解析也放到这上面来。

Typekit

原本是用 Google Font 提供的实验性的思源黑体 Webfont，然后我发现 Typekit 那边居然有思源宋体可用，于是就切换到了 Typekit，这也是一个值得赞美的服务，现在使用甚至连 Typekit banner 都不用展示了。我是有计划在某个地方专门加上一个说明的。拉丁字母没有找到其它比较好用来搭配思源宋体的衬线字体，所以还是使用了思源宋体自带的这一套，勉强可用。

分页

目前的日志已经有 490+ 篇，而且还有一些旧日志没有导入完毕，最后还是选择对日志列表进行分页。因为 Gatsby.js 有 SSR，所以是仿照了 gatsby-plugin-paginate 和官方指导文档，生成了分页的目录。因为不希望让页面太长，所以每页显示 10 篇，但是这样子页数又显得有点过多。结论是还是需要有一个站内搜索。

i18n

这个其实有一点装模作样，毕竟基本所有日志都是中文的。只不过自己想着之后也许会写一些英文的技术类文章，或者用法语练一练笔，再或者学习一下日语，于是就加入了 i18n 功能。实现部分参考了官方的日志，因为我不喜欢写 json，于是源代码换成了 yaml。

这里面的实现我觉得还不是很完美，翻译资源只能在 build 过程中加载，给 develop 带来了一些困难。如果能够直接从 Gatsby.js 的 graphql API 里面拿数据就好了，但是我并不是很了解如何在组件之外调用 query。虽然也有强行摸出一个组件，然后在组件的生命周期里面载入资源的方案，但是稍微感觉有点取巧，就没有去做。

语言选择组件需要做一个对话框或者弹出框。思考了一下自己摸一个轮子和使用组件库的性价比之后，我选择使用 blueprint.js，没有办法，虽然写一个组件也挺锻炼人的，但是这个任务实在过于支线。

有一个小问题，i18next 的 xhr backend 在 SSR 的时候也会请求资源，于是编译日志就会有一些报错信息干扰。因为没有影响到使用，所以之后再看了。

阅读时间

Medium 的日志会有一个阅读时间的提示，虽然主要的作用是给读者评估文章的长短。因为 Gatsby 的 markdown 处理插件并不能统计 CJK 文字的字数——目测是使用空格来算词的——我又使用 word-count 包实现了一个字数统计以及阅读时间估算。写的过程中大致搜索了一下一般的汉语阅读速度，但是没有找到答案，我也不想为这个数字专门去试验，最后就假定一分钟可以阅读 160 个字（词）了。

接下来还有一些思考过但是还没有想到好方案，或者没有足够时间去做的功能

全站搜索

如果是拉丁文字的搜索的话，Gatsby.js 是有一些现成的搜索方案的，比如编译期载入数据，索引并使用 lunr 或者 elasticlunr 进行纯前端检索。在我这里的话就需要解决两个主要问题：CJK 分词和数据量控制。

对于分词，目前来看可能只有用第三方方案比如结巴分词的 node 移植或者集成、chinese-tokenizer 等，也需要考虑怎么样集成到 lunr 当中——虽然是有其它语言的分词器样例的。数据量的问题，我也的确不是很确定 500+ 日志，几万字的内容的索引对于网络是不是友好。

Gatsby 之外的方案，就是第三方搜索了。Google Custom Search 可能算是最好的，可惜需要科学上网。Bing 也有一个 Azure 上的 Custom Search，但是貌似是收费业务。Algolia 有免费的支持，就是需要编译期自己上传索引。

响应式与可访问性，PWA

这又是一个很宏大的主题了，估计还需要往后放。