将多说评论系统迁移到Disqus

最近几天看到多说官方发布消息, 多说评论系统将于2017年6月1日正式停止服务, 是时间考虑将评论系统换一下了.

当初使用多说, 一是因为是国内的服务, 速度会比较快, 二是国内用的人确实不少, 沟通起来可以比较方便.

现在多说不能使用了, 其实大可以直接将博客中的多说下掉, 但是以前的评论就没有了. 这些评论是从使用 WordPress 时就积累下来的, 如果丢失了, 真的比较可惜.

所以将评论迁移, 第一个考虑切换的目标就是使用人最多的 Disqus 了.

网上找了一番, 发现迁移脚本都是时间比较长的了, 害怕会有些变化, 所以打算自己写一个.

duoshuo2disqus

参考了 Disqus 导入时的格式 WXR, 然后使用 Node 处理一下多说导出的数据.

处理数据的时候还遇到了一个问题. 多说导出的文章和评论中, 都有一个 thread_idpost_id 的字段. 这两个字段导出的类型为数字类型, 而且非常大. 导致 Node 在 require 这些内容的时候, 数字不准确, 造成非常多的重复和错乱.

解决办法就是, 先把导出的内容中, 这两个字段由数字类型, 转为字符串类型, 即可解决.

在使用 JS 的项目中使用 ESLint 强制进行 code style check

code style 是一个经常被大家提起的东西. 当项目中人少的时候, 大家一般都能有一个约定, 并去遵守.

但是当项目变大, 或者有新的开发人员加入进来的时候, code style 不一致的问题就会变大. 甚至有些写法不规范的地方, 导致看代码的时候感觉不舒服. 假如每个人喜欢的风格不一致, 当编辑代码的时候, 又使用了代码自动格式化工具按照自己的喜好进行格式化, 那么当提交到 git 的时候, 会出现全红全绿的情况, 特别不利于 review.

因此应该采取一种手段进行约束.

所以我采用了 git hook 的方式在本地强制进行 code style check. 当 check fail 时, 直接拒绝 commit. 防止出现为了修复 code style 而添加的一些意义不大的 commit.

  1. 项目安装 ESLint, 并配置 eslintrceslintignore
  2. 在项目的 .git-hooks 目录下添加如下脚本, 来源 https://gist.github.com/linhmtran168/2286aeafe747e78f53bf

    #!/bin/sh
    
    STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep ".jsx\{0,1\}$")
    
    if [[ "$STAGED_FILES" = "" ]]; then
      exit 0
    fi
    
    # Check for eslint
    ESLINT="./node_modules/.bin/eslint"
    if [[ ! -e $ESLINT ]]; then
      echo ""
      echo "  \033[41mPlease use <npm install> to install ESlint\033[0m"
      exit 1
    fi;
    
    PASS=true
    echo ""
    
    for FILE in $STAGED_FILES
    do
      $ESLINT "$FILE"
    
      if [[ "$?" == 0 ]]; then
        echo "  \033[32mESLint Passed: $FILE\033[0m"
      else
        echo "  \033[41mESLint Failed: $FILE\033[0m"
        PASS=false
      fi
    done
    
    if ! $PASS; then
      echo "\n\033[41mCOMMIT FAILED:\033[0m Your commit contains files that should pass ESLint but do not. Please fix the ESLint errors and try again.\n"
      exit 1
    else
      echo "\n\033[42mCOMMIT SUCCEEDED\033[0m\n"
    fi
    
    exit $?
    
  3. package.json 中进行配置 postinstall 为如下内容

    cp .git-hooks/* .git/hooks/
    

这样, 每次 npm install 之后, 都会将检查脚本放置到正确的位置. 每次 git commit 的时候, 都会进行 code style check.

我们目前的项目中, 使用了 FIS3 进行开发, 所以我们开发时, 会有对应的 npm run dev 这样的 script, 为了确保检查脚本能被正确放置, 我在 npm run dev 中也会去跑一遍 npm run postinstall. 这样, 就不会出现, 由于原来已经 npm install 过了, 而没有把检查脚本正确放置的情况.

webpack 的 chunkId 是不是一个好的概念

webpack 因为有各种各样的 loader, 可以让我们把所有的东西都使用相同的 require 写法进行加载, 同时还可以配合各种 compiler, 让我们从现在就可以享受到 ES6 给我们带来的便利, 所以 webpack 受到了大家的欢迎, 成为 2015 - 2016 特别受欢迎的打包及模块化方案.

但是在使用 webpack 的时候, 遇到了一个不小的问题, webpack 的 chunkId 对于永久缓存的支持.

假设我们有这样一个 SPA 页面场景, 有一个路由文件 route.js, 会在此文件中使用 webpack 的 code spliting 写法, 按需加载文件.

在 route.js 中分别对应三个页面(foo, bar, baz), 按需加载对应的入口文件. 在入口文件中, 会再分别加载各个子页面依赖的文件.

当我们使用 webpack 进行 build 后, webpack 会给每个文件分配一个 chunkId, 这个 chunkId 是随着 webpack 处理到的文件的数目而进行递增的. 一种结果是类似于下面这样的, 文件后面的括号中是生成的 chunkId 号

如果我们需要在foo.js中增加一个依赖 dep4.js, 那么相应的 chunkId 会变成类似于下面这样

我们只增加(或删除)了一个文件, 却导致了多个文件的 chunkId 变化, 这样就导致多个文件的内容发生了变化. 那么当重新发布后, 其实有的页面的内容根本不需要变化, 但是仅仅是因为 chunkId 变化, 而导致需要重新下载这些文件, 使得没法使用浏览器已经缓存的文件.

如果你的页面有几十个, 每次添加或者删除一个文件后, 都会导致几乎所有的文件的浏览器缓存失效.

我们期望的结果是, 每当我们修改一个文件后, 只有依赖此文件的文件会更新, 而其它的文件不会发生变化. 当重新发布后, 只会去重新下载那些已经被更新的文件, 这样我们就可以做到类似于增量更新的效果.

但是 webpack 采用的 chunkId 的概念好像没办法避免这样的问题. 如果将 chunkId 换成依赖文件的路径, 是不是可以减少这种问题的发生呢?

使用 System.js 作为 ES6 的加载器

随着 ES6 的慢慢普及以及各浏览器对于 ES6 的支持, 在新开的项目或者对于老项目的更新上, 大家纷纷采取拥抱 ES6 的态度. 因为即使有的浏览器目前对于 ES6 的支持还不太高, 但是我们可以使用 webpack, 加上 webpack 中的各种 loader, 我们可以很方便的将 ES6 编译为普通的 ES5 代码, 然后跑在所有的浏览器上.

webpack 为大家提供了 webpack-dev-server 用于开发环境, webpack-dev-server 可以方便的进行代码调试, reload 等功能.

但是我在使用 webpack 搭配 webpack-dev-server 的时候, 由于项目很大, 文件特别多, 所以遇到了一个很大的问题, rebuild 等待的时间太久了, 完全不如我原来没有使用 webpack 时保存代码后手动刷新浏览器来的快速. 但是因为我使用了 webpack 进行合并压缩, 我不得不等待整个项目编译完成才能进行调试.

为了解决这个问题, 我写了 webpack-source-code-loader, 并且写了一篇文章 在Angular.js项目中使用异步加载(五).

后来接触到了 System.js, 发现其实我的需求完全可以使用 System.js 进行解决. 因为 System.js 可以通过 Babel.js 或者 TypeScript 在浏览器中完成 ES6 => ES5 的编译工作. 具体例子请看我写的 demo

在使用的时候我发现, 使用 TypeScript 时会比使用 Babel.js 有更快的编译速度, 同时还可以使用 TypeScript 提供的类型系统, 真的很好. 并且, System.js 和 Babel.js@6.x 有兼容性问题, 目前还只能使用 Babel.js@5.x 才能进行正常工作.

综上, 以后开始一个新的项目的时候, 完全可以先不管 webpack 的配置, 可以直接使用 System.js 来加载 ES6 源码, 等到整个项目完成的差不多了, 再考虑使用 webpack 或者其它构建工具进行工程化也不迟.

近期文章

相关页面