README
如何更优雅地编写(copy)页面
背景
开门见山的说,在日常编写业务页面时,我们深知代码风格的统一(fu zhi zhan tie)尤为重要。
起初我们没有 对象 的概念时会把功能点平铺直叙,即 面向过程编程 输出。简单粗暴。
这时有的观众可能会以为这是一篇水 面向对象 的重复轮子马上右上角劝退。
通俗易懂的图解
Js面向对象
传送门
少侠请留步,即便玩的一手好继承,在很多 相似 的业务页面里,我们深知 组合优于继承
。
以上,有的观众已经聪明到把很功能组件一拆再拆。新的业务简单得一匹,把组件拿出来复制粘贴就是一把梭。
痛点
终于进入正题...
即便是复制粘贴,内心还是很抵触的好吧。
若不是真的方便,谁又愿意当一个copyer
老实人就要讲老实话,就算是复制粘贴了。随着项目更迭,新的业务页面要复制的点也越来越多 越来越多 越来越...
重复性工作,繁琐而且浪费时间
copy过来的模板容易存在无关的代码
项目中有很多需要配置的地方,容易忽略一些配置点,进而埋坑
人工操作永远都有可能犯错,建新项目时,总要花时间去排错
遂...一款为业务而生的脚手架应运而生。
姑且取名为,终极无敌上帝视角之老夫就是一把梭复制粘贴之可配置化页面组件生成脚手架 。
别BB了贴代码我自己看好吧
基本思路
- 把页面代码块作为模板(糅合所有可配置的功能)
- 控制台选择需要的功能
- 渲染输出
简单的三步,跟把大象放入冰箱基本无异好吧。
怎么做
创建一波 npm 工程
npm init
// node工程下package.json中的bin字段可以定义命令名和关联的执行文件.
...
"name": "pims-cli",
"version": "1.0.0",
"description": "一个简单的脚手架工具",
"bin": {
"pims": "./bin/pims"
...
由上面代码块可知,其实和我们在当前目录下的 ./bin/pims
是有一个脚本的。
commander.js
这里用到 commander.js 工具进行解析命令和参数。
#!/usr/bin/env node
const program = require('commander') // npm i commander -D
const config = require('../package.json')
program.version(config.version, '-v, --version')
.command('init', 'init project')
.parse(process.argv)
语法必然是自行看 api
的,这里不推荐 action
写回调, command
拿具体页面方法显得更模块化。
以上为止,我们已经建立了 npm
工程, 且可执行一定的命令
node ./bin/pims init <xxx> // 工具主功能
node ./bin/pims -v //版本
node ./bin/pims -h
inquirer.js
当然我们还需要拿到用户命令行输入,且存为变量后去控制模板的组件输出。
const inquirer = require('inquirer') // npm i inquirer -D
inquirer.prompt([
{
name: 'path',
message: '路径',
},
{
name: 'tabs',
message: '标签表格',
type: 'confirm',
default: false
},
{
name: 'rowSelection',
message: '表格列选择',
type: 'confirm',
default: false
},
{
name: 'columns',
message: '配置列',
type: 'confirm',
default: false
}
]).then(answers => {
console.log(answers)
})
这里提一点,即便是用了
Promise
,还是会出现回调地域的问题。解决的办法也很简单,在then
里再把Promise
抛出来即可。
handlebars
到了这里也是最后一步了。把模板代码根据 inquirer
返回的变量通过模板语法 handlebars 改造以后复制粘贴到项目目录。
当然语法简单的自己看 api
即可。需要注意的点如下:
// 常规渲染
export default connect(state => state['{{path}}'])(View)
// 保留 jsx 输出, \{{}} 很灵性
<div style=\{{ width: 512 }}>
...
</div>
其他
npm 发布
npm link // 本地开箱即用
npm publish // 发布远端给小伙伴用
download-git-repo
有的观众可能觉得模板和脚手架解耦开来会显得帅气一点
download-git-repo 你值得拥有好吧
总结
贴代码是不可能贴代码的了,被大佬发现代码写得贼烂的机会是不可能出现的。
这里只是提供下思路,用脚手架封装自己的业务代码做模板是较为舒服的方式。当然这个思路也是我借鉴来(copy)的~