分类目录归档：技术

Vue Router 应该如何实现限制用户登陆的功能？

在 Vue Router 中，并没有一个所谓的默认首页的功能，所以我一直都很好奇，应该如何实现这样的功能？如果没有这样的功能，又如何实现一个项目的默认显示页面呢？

今天，终于有了答案。

这样的功能不是内置的，不过你可以通过 router.beforeEach来实现这个功能。

具体的思路是，在跳转前，对目标路由进行检测，如果目标路由的 meta 信息中写明了需要进行鉴权，就跳转到默认的登陆页面。这样，就可以实现默认显示登陆页面的功能。

具体可以参考的代码

/// 省略引用的代码
let router = new Router({
  mode:"history",
  base:base,
  routes: [
    {
      path: '/login',
      name: 'login',
      component: Login,
      meta: { title: '登陆' }
    },
    {
      path: '/',
      name: 'home',
      component: Home,
      meta: { title: '首页', requireLogin:true }
    }
  ]
})
router.beforeEach((to, from, next) => {
  const { name,meta } = to;
  const { requireLogin } = meta; // 提取登陆 标志
  if(name === 'login'){
    return next();
  }
  const needLogin = requireLogin;
  if(needLogin){ // 如果判断需要登陆，就跳转登陆。
    return next({
      name:"login",
      params:{
        back: to
      }
    })
  }
  next();
})

Vue 项目引入 Normalize.css 来进行格式的初始化

发表评论

以前，我们使用 reset.css 来完成 HTML 样式的初始化，借助这个 css 文件，可以将多个不同平台，不同系统下的基础组件的样式整合一致。

如今，我们可以使用 Normalize.css 来完成这个工作，也非常简单

yarn add normalize.css

安装完成后，在 vue 的主文件，引入即可

import 'normalize.css/normalize.css'

Vue Cli 3.0 创建的项目中加入 Stylus 支持

发表评论

在使用了 Stylus 编写了小程序的一些样式后，我被这种显然更加简洁的工具折服了。

在新的 Vue 项目中，我希望继续使用 Stylus 来编写样式，只需执行如下代码

yarn add stylus stylus-loader

发现官方没有 plugin ，可以去做一个

使用Prettier、Husky 和 lint-staged 进行 Commit 前处理

发表评论

在编写代码时，如果你的代码中配置了 ESLint，而你自己没有运行 ESLint ，可能会导致你的 CI build 失败。因此，在 Commit 前加入格式的修正是很有必要的。

在这篇文章中，我将向你分享，如何使用 Prettier、Husky、Lint-staged 对项目进行 commit 前的格式修复，以及如何配合 Sublime Text 使用。

1. 全局安装 Prettier

想要使用 Prettier 进行格式修复，首先，你需要安装 Prettier ，在命令行中执行如下命令：

npm install --global prettier

2. 在 Sublime Text 中安装 JSPrettier

然后，在 Sublime Text 中使用 Package Control 来安装拓展 JSPrettier

在 Sublime Text 中唤起 Package Control ，执行 Install Pacakge ，并安装其中的 JsPrettier

3. 在项目根目录中添加 Prettier 的配置文件

你可以在项目的根目录下创建一个 .prettierrc 的文件，然后在其中加入配置项目，具体的配置项目可以参考官方的 Options 页面

比如，如下是我的配置文件

{
  "singleQuote": true,
  "semi": false,
  "tabWidth": 2
}

Options 页面地址：https://prettier.io/docs/en/options.html

4. 使用 Sublime 进行格式修正

当你配置好了配置文件以后，打开 Sublime Text，找到一个 JS 文件，并打开，这时，在代码中点击右键，可以看到一个 JSPrettier Format Code ，点击这一项，就可以自动根据你所创建的配置文件，进行界面的修正了。

5. 安装 Husky 和 Lint-staged 配置 Pre-commit 检查

接下来，我们来配置 Precommit 的检查

首先，你需要安装 Husky

cnpm install lint-staged husky --dev --save

安装完成后，修改你的 packages.json 文件，在其中添加如下代码

  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,json,wpy}": ["prettier --write", "git add"]
  }

然后保存。这样，就完成了 precommit 的格式检查了。

6. 测试 commit

接下来，你可以随便修改一个文件，然后执行 git commit操作，你可以看到其会输出如下的内容

参考链接：https://prettier.io/docs/en/precommit.html

Sublime Text 3 如何配置文件后缀关联？

发表评论

在使用 Sublime Text 开发 WePY 时，会遇到一个问题, 如何让 Sublime Text 识别 .wpy 文件为 Vue 格式，并进行高亮呢？

你可以这样操作

1. 安装 Vue Syntax Highlight 插件

你可以使用 Package Control 来安装 Vue Syntax Highlight 插件，安装完成后，你打开任何一个 .vue 文件，就会发现代码已经被高亮了，就说明你的你的插件安装成功了。

2. 配置 wpy 文件的关联

接下来，你需要打开任何一个 wpy 文件，然后点击菜单栏中的 View-Syntax-Open All Current Extension as…-Vue Component,这样，就可以完成了 .wpy 文件的 Vue 关联，后续，你再打开 .wpy 文件，就会自动使用 Vue 语法高亮插件了。

本站在用的一些WordPress插件

1条回复

Akismet Anti-Spam

WordPress 官方出的，用于屏蔽垃圾评论的。基本上每个用 WordPress 的人都会装。

CB Change Mail Sender

一个用于修改 WordPress 自动发信时的 Sender 和 Sender Email Adress 的插件。

cos_slug_translator

将文章的 Slug 从中文转换为英文的插件。后续我会重写这个插件，更简单使用，以及发布到官方的插件市场。

Jetpack

JetPack 用于古腾堡编辑器中的新 Block

Link Share

我自己开发的插件，效果可以参考顶部菜单栏中的分享页面。

LinkShare

No Self Pings

用于控制自己的文章不要向内产生 PingBack

WP-Optimize

WordPress 优化插件

WP-PostViews

WordPress 访问量统计插件

在一个老旧的项目里引入 Mocha 测试

发表评论

由于要做每日极漫小程序，也就需要其背后的漫画翻译组活跃起来，随之，就需要翻译组背后的工具正常使用，不过 LCTC-CLI 已经很久没有更新了，便趁这个机会，恢复这个工具的更新。

对工具的更新，首先应当做的，自然是补全测试，这样才好确保自己的改动不至于让老项目无法正常运转。

安装 Mocha

首先，执行命令，将 Mocha 安装在开发依赖中。

npm install --save-dev mocha

随后，再修改 package.json 文件中的 scripts 部分的内容，将 test 对应的命令改为 mocha，效果如下

{
   ...
   "scripts": {
       "test": "mocha"
   }
   ...
}

这样，你就可以运行 npm test 来执行测试了。

编写测试

安装完成后，你可以运行npm test 命令，来执行测试，这时，你会发现报错如下：

Warning: Could not find any test files matching pattern: test
No test files found

这是因为你并没有创建测试文件夹和测试文件，所以自然会报错。

执行如下命令，来创建一个测试目录和对应的测试文件

mkdir test
touch test/test.js

再次执行，你就可以看到，测试成功通过。

0 passing (3ms)

虽然是告诉你，你并没有通过任何的测试代码（所以是 0 passing）

接下来，编写第一个测试，打开 test/test.js，然后填入下述代码

var assert = require('assert');
describe('Array', function() {
  describe('#indexOf()', function() {
    it('should return -1 when the value is not present', function() {
      assert.equal([1,2,3].indexOf(4), -1);
    });
  });
});

然后，再次执行 npm test ，这样，就完成了第一个测试，你会看到这样的输出

Array
     #indexOf()
       ✓ should return -1 when the value is not present
1 passing (7ms)

这样，就完成了初步的 Mocha 的引入和测试。接下来，开始继续编写实际的测试即可。

不过，我在编写测试时发现，原先的代码结构极为不合理，因此，决定直接重写了。使用 TDD 的思想，完成重写这个工具。

警惕那些让你省力的工具

发表评论

作为一个 Engineer ，前「后端工程师」，我用过不少后端框架，比如 PHP 里的 ThinkPHP（3.x）时代，Laravel（5.x）时代，Python 的 Flask、Django ，Ruby 里的 Rails。

其中，近两年我用的最多的是 Laravel 和 Django ，原因是他们提供了一个很重要的 Feature ，就是 Admin Panel。只不过 Django 是官方自带的（Django Admin），而 Laravel 使用的是第三方 Pacakge （Laravel-Admin）。

借助这两个工具，可以快速的生成一个好用且效果非常不错的管理后台，让并不是很喜欢做界面的我大呼爽快（实际上我并不是不喜欢写 JS，我仅仅是不喜欢写 CSS，现在的组件化开发大大的让我解脱出来）。只需要很少的一些代码，就能够完成自己想要的效果。

不过，这样让我产生了一定的依赖，现在要做一些和 Web 相关的事情时，我都会优先考虑 Laravel 和 Django ，因为他们提供了 Admin 后台，可以让我在很长的一段时间内不去关注后台的逻辑，更加专注于前台的开发。

这很好，很敏捷。但是也让我失去了自己开发业务后台的耐性，毕竟，已经有更加简单的实现方式了，为什么还要为难自己呢？

但是，如果你想要认认真真去做一个项目的时候，会发现这种高度简化的代码，让你的拓展性非常的差，你无法更好的去做好自己应该做的事情。

所以，为什么不从一开始就自己写后台呢？虽然慢了点，但是对于你自己来说，也是足够的。随着你自己的开发项目的变多，完全可以做一套你自己的通用后台，完全符合你自己的要求、想法。那才是你真正需要的。

应该选前端还是选后端？

发表评论

其实，说到开发，就难免会遇到一个问题？

你是想做前端还是想做后端？

在大企业内，前端和后端差距都不大，不过从个人成长角度来看，二者又有所不同。

从技术成长的角度来看，前端和后端的选择并不会影响你最终成为技术大牛。任何一个领域，都有足够多的人不努力，等待着别人去教他们，只要你愿意努力，很容易就超过他们。所以，在这篇文章中，我并不想从技术的角度考虑。

这个想法是这两天在喂羊的间隙想到的。

前端和后端的区别是什么？区别在于前端更接近用户，而后端离用户更远。

在传统的开发模式下，前端切图，生成模板丢给后端，后端加入模板的标签，渲染界面。

在如今的开发模式下，后端提供 API ，前端负责完整的交互、路由等工作，需要花费大量的时间和精力在与用户相关的内容上。这使得前端开发人员，有更多的机会直面用户需求。而后端更多的是面对业务，根据一个个业务封装编写对应的 API，这使得后端无法完整的了解用户的需求到底是什么。

为什么要离用户近？

我见到过很多程序员，他们只关注于技术本身，而不在意产品、业务方面的事情，但是如果你有着自己做点什么东西的想法，那么，就一定要离用户近，接触到用户真实的需求，并去分析，为什么用户的需求产品经理给出的方案却是这个样子的。

离用户更近，离钱更近。

不过，虽然前端可能更适合一个想要自己做事情的人，但是你反而应该先去以后端的身份加入到整个生态中，因为在一开始的时候，你还有足够的精力和热情去研究技术，随着时间的流逝，你对技术的兴趣会越来越小，会花费大量的精力在产品、推广上。所以，前期关注底层的技术，后期关注用户、体验层面的东西。

为什么一个现代化的框架应该具备 Migration 功能

发表评论

在过去刀耕火种的编程年代，程序员写代码的时候都是手动创建表

但是，在开发过程中，难免会遇到需要对表结构进行修改，在一些小型团队中，尚且可以通过喊一声，大家都执行同样的操作来完成，确保各自的数据结构的一致性。

随着开发流程的变长、开发人员数目的增多、远程工作的流行，这种方案显然不可行。

因此，就出现了 Migration 。Migration 是将数据库的变化以代码的形式存储起来。一个人在进行数据库修改时，使用 Migration 进行操作，其他人只要执行对应的 Migration ，就可以进行数据库结构的同步。

一个现代化的框架，应该有 Migration。

TravisCI 运行 mocha 时报错 SyntaxError: Use of const in strict mode. 怎么办？

发表评论

如果你未指定 Node.js 的版本时，会以 0.10.2 版本运行，此版本无法使用 const ,所以，需要指定你的 Node 版本。

WePy 整合云开发

发表评论

由于工作上的原因，有需求要使用 WePy，刚好，有了云开发的契机，就决定研究一下。

初试 WePY

想要做云开发和 WePY，首先要先熟悉 WePY。 WePY 其实之前就听说过，不过自己一直没有使用，更多还是习惯用小程序原生写法来进行开发。

后续，也用过一些其他的框架，比如 MinUI 。

和 MinUI 相比，WePY 给我来说最大的感受是提供了 promise 的支持和 async/await 的支持，这个支持可以极大的改善 JavaScript 编程时遇到的 Callback Hell 的问题，可以让我们更加愉悦的开发。

此外，我比较看重的特性是支持外部的 NPM 包，支持 NPM 包意味着可以更好的使用 JavaScript 原本的工程化的产品，也是大大提升生产力的特性。不过，相比于 Promise 的支持和 async/await 的支持，这个如今已经被微信小程序官方团队所支持的 npm 也显得不那么重要了。

做一个 WePY 的 tempalte 吧！

在看文档时注意到，WePY 是使用 wepy init 来进行初始化的，而且可以使用 wepy list 来查看项目的模板。发现了其中有一个基于 ZanUI 的模板。

由于 ZanUI 及更名后的 VantUI 我都比较熟悉，所以从他下手，去研究一下如何制作 WePY 的模板。

复制 repo名/模板名，并在前面加上 github 的域名，就找到了对应的 repo 。

简单的看了一下项目的文件，发现其中并没有什么特殊的，需要指明初始化内容的文件，所以猜测大概率是不需要进行单独的配置的。

这方面 WePY 的文档做的不是很好，我在文档中并没有找到相关的说明。如果可以的话，希望开发者可以加一个功能，比如加上一个 .wepy-template ，可以在里面加入一些交互式的问题，从而来让用户设置一些内容。

在确定了模板其实并不困难以后，我就开始做自己的云开发模板了。

如何做一个模板

做一个模板只需要三步

下载官方的 empty 模板
加入你自己的代码
上传到 Github

说起来简单，不过，在实际制作时，还是应当注意一些问题：

初始化 Empty 模板后，尽快使用 git init 来初始化版本控制。这是因为云开发是与小程序的 AppID 进行绑定的，如果前期没有做好控制，容易出现后续将 AppID 加入了版本追踪。所以在一开始，我就将项目进行了初始化，方便后续的回溯。
上传到 Github 时，应当注意配置 Readme，在我之前的文章中，曾经提到过我们应当尽可能的交付一些产品给世界，好让世界根绝我们所交付的产品进行估值。特别是对于模板类型的 repo ，更是需要一个非常好的 Readme ，来引导别人去使用自己的模板
制作完成模板后，记得自己使用 wepy init 命令将整个过程完整的走一遍。确保你的模板是可用的。

在使用 WePY 过程中遇到的一些问题

CloudFunctionRoot 的设定问题

在做第一个版本的时候，我是将云函数的目录放在 src 目录下，后续，在运行时发现， WePY 会自动编译云函数的目录，导致出错。不得已，我将云函数的目录放置在了项目的根目录。

当时在研究这部分时，我试图去寻找 wepy.config.js文件的配置说明，希望找到一个 exclude 配置项目，来忽略一部分目录，可惜，我并没有找到。

WePY 下的一些定义问题

在使用原生写法的时候，我常常会在 Page({}) 函数外部放上一些引用。比如这样

const database = wx.cloud.database()
const storeCollection = database.collection('store')
Page({
    onReady():function(){
        // some code
    }
})

在 WePY 中我试图将代码放在 Page 实例的内部，不过会导致报错，因此，我不得不废弃这样的写法，改用 constructor 来实现。

 export default class Index extends wepy.page {
    constructor () {
      super()
      this.db = wx.cloud.database()
    }
    onLoad() {
      console.log('onLoad')
      console.log(this.db)
    }
}

对 getApp 报错

在 WePY 中，由于传承了 Vue 的思想，并没有提供对 getApp的 hack ，不过在实际的测试过程中，发现 getApp() 依然可用。

如果不引入 Redux 之类的状态管理工具的情况下，getApp() 的单例模式作为一个全局的 Bus 来进行数据的传递还是非常方便的。

关于 WePY 的其他

总的来说， WePY 是一个值得尝试的框架，单纯 Async/Await 的引入，可以让你的代码变得更加简洁易懂。特别是如果你的项目需要长期运转的情况下，整洁的代码会帮助你的项目成功。

此外，如果你很习惯于 Vue 的写法，那么 WePY 不容错过，computed 属性还是非常实用的。