在使用了 Stylus 编写了小程序的一些样式后,我被这种显然更加简洁的工具折服了。
在新的 Vue 项目中,我希望继续使用 Stylus 来编写样式,只需执行如下代码
yarn add stylus stylus-loader
发现官方没有 plugin ,可以去做一个
在使用了 Stylus 编写了小程序的一些样式后,我被这种显然更加简洁的工具折服了。
在新的 Vue 项目中,我希望继续使用 Stylus 来编写样式,只需执行如下代码
yarn add stylus stylus-loader
发现官方没有 plugin ,可以去做一个
在编写代码时,如果你的代码中配置了 ESLint, 而你自己没有运行 ESLint ,可能会导致你的 CI build 失败。因此,在 Commit 前加入格式的修正是很有必要的。
在这篇文章中,我将向你分享,如何使用 Prettier、Husky、Lint-staged 对项目进行 commit 前的格式修复,以及如何配合 Sublime Text 使用。
想要使用 Prettier 进行格式修复,首先,你需要安装 Prettier ,在命令行中执行如下命令:
npm install --global prettier
Code language: PHP (php)
然后,在 Sublime Text 中使用 Package Control 来安装拓展 JSPrettier
在 Sublime Text 中唤起 Package Control ,执行 Install Pacakge ,并安装其中的 JsPrettier
你可以在项目的根目录下创建一个 .prettierrc
的文件,然后在其中加入配置项目,具体的配置项目可以参考官方的 Options 页面
比如,如下是我的配置文件
{
"singleQuote": true,
"semi": false,
"tabWidth": 2
}
Code language: JSON / JSON with Comments (json)
Options 页面地址:https://prettier.io/docs/en/options.html
当你配置好了配置文件以后,打开 Sublime Text,找到一个 JS 文件,并打开,这时,在代码中点击右键,可以看到一个 JSPrettier Format Code ,点击这一项,就可以自动根据你所创建的配置文件,进行界面的修正了。
接下来,我们来配置 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"]
}
Code language: JavaScript (javascript)
然后保存。这样,就完成了 precommit 的格式检查了。
接下来,你可以随便修改一个文件,然后执行 git commit
操作,你可以看到其会输出如下的内容
参考链接:https://prettier.io/docs/en/precommit.html
在使用 Sublime Text 开发 WePY 时,会遇到一个问题, 如何让 Sublime Text 识别 .wpy
文件为 Vue 格式,并进行高亮呢?
你可以这样操作
你可以使用 Package Control 来安装 Vue Syntax Highlight 插件,安装完成后,你打开任何一个 .vue
文件,就会发现代码已经被高亮了,就说明你的你的插件安装成功了。
接下来,你需要打开任何一个 wpy
文件,然后点击菜单栏中的 View-Syntax-Open All Current Extension as…-Vue Component,这样,就可以完成了 .wpy
文件的 Vue 关联,后续,你再打开 .wpy
文件,就会自动使用 Vue 语法高亮插件了。
WordPress 官方出的,用于屏蔽垃圾评论的。基本上每个用 WordPress 的人都会装。
一个用于修改 WordPress 自动发信时的 Sender 和 Sender Email Adress 的插件。
将文章的 Slug 从中文转换为英文的插件。后续我会重写这个插件,更简单使用,以及发布到官方的插件市场。
JetPack 用于古腾堡编辑器中的新 Block
我自己开发的插件,效果可以参考顶部菜单栏中的分享页面。
用于控制自己的文章不要向内产生 PingBack
WordPress 优化插件
WordPress 访问量统计插件
由于要做每日极漫小程序,也就需要其背后的漫画翻译组活跃起来,随之,就需要翻译组背后的工具正常使用,不过 LCTC-CLI 已经很久没有更新了,便趁这个机会,恢复这个工具的更新。
对工具的更新, 首先应当做的,自然是补全测试,这样才好确保自己的改动不至于让老项目无法正常运转。
首先,执行命令,将 Mocha 安装在开发依赖中。
npm install --save-dev mocha
随后,再修改 package.json
文件中的 scripts
部分的内容,将 test
对应的命令改为 mocha
,效果如下
{
...
"scripts": {
"test": "mocha"
}
...
}
Code language: JavaScript (javascript)
这样,你就可以运行 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);
});
});
});
Code language: JavaScript (javascript)
然后,再次执行 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。
如果你未指定 Node.js 的版本时,会以 0.10.2 版本 运行,此版本无法使用 const ,所以,需要指定你的 Node 版本。
由于工作上的原因,有需求要使用 WePy,刚好,有了云开发的契机,就决定研究一下。
想要做云开发和 WePY,首先要先熟悉 WePY。 WePY 其实之前就听说过,不过自己一直没有使用,更多还是习惯用小程序原生写法来进行开发。
后续,也用过一些其他的框架,比如 MinUI 。
和 MinUI 相比,WePY 给我来说最大的感受是提供了 promise 的支持和 async/await 的支持,这个支持可以极大的改善 JavaScript 编程时遇到的 Callback Hell 的问题,可以让我们更加愉悦的开发。
此外,我比较看重的特性是支持外部的 NPM 包,支持 NPM 包意味着可以更好的使用 JavaScript 原本的工程化的产品,也是大大提升生产力的特性。不过,相比于 Promise 的支持和 async/await 的支持,这个如今已经被微信小程序官方团队所支持的 npm 也显得不那么重要了。
在看文档时注意到,WePY 是使用 wepy init
来进行初始化的,而且可以使用 wepy list
来查看项目的模板。发现了其中有一个基于 ZanUI 的模板。
由于 ZanUI 及更名后的 VantUI 我都比较熟悉,所以从他下手,去研究一下如何制作 WePY 的模板。
复制 repo名/模板名,并在前面加上 github 的域名,就找到了对应的 repo 。
简单的看了一下项目的文件,发现其中并没有什么特殊的,需要指明初始化内容的文件,所以猜测大概率是不需要进行单独的配置的。
这方面 WePY 的文档做的不是很好,我在文档中并没有找到相关的说明。如果可以的话,希望开发者可以加一个功能,比如加上一个 .wepy-template
,可以在里面加入一些交互式的问题,从而来让用户设置一些内容。
在确定了模板其实并不困难以后,我就开始做自己的云开发模板了。
做一个模板只需要三步
说起来简单,不过,在实际制作时,还是应当注意一些问题:
git init
来初始化版本控制。这是因为云开发是与小程序的 AppID 进行绑定的,如果前期没有做好控制,容易出现后续将 AppID 加入了版本追踪。所以在一开始,我就将项目进行了初始化,方便后续的回溯。wepy init
命令将整个过程完整的走一遍。确保你的模板是可用的。在做第一个版本的时候,我是将云函数的目录放在 src
目录下,后续,在运行时发现, WePY 会自动编译云函数的目录,导致出错。不得已,我将云函数的目录放置在了项目的根目录。
当时在研究这部分时,我试图去寻找 wepy.config.js
文件的配置说明,希望找到一个 exclude
配置项目,来忽略一部分目录,可惜,我并没有找到。
在使用原生写法的时候,我常常会在 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)
}
}
在 WePY 中,由于传承了 Vue 的思想,并没有提供对 getApp
的 hack ,不过在实际的测试过程中,发现 getApp()
依然可用。
如果不引入 Redux 之类的状态管理工具的情况下,getApp() 的单例模式作为一个全局的 Bus 来进行数据的传递还是非常方便的。
总的来说, WePY 是一个值得尝试的框架,单纯 Async/Await 的引入,可以让你的代码变得更加简洁易懂。特别是如果你的项目需要长期运转的情况下,整洁的代码会帮助你的项目成功。
此外,如果你很习惯于 Vue 的写法,那么 WePY 不容错过,computed 属性还是非常实用的。