子咻
新的一年 --- 之前因为上家公司的经营出了问题，年前的大裁员，过了一个漫长的春节。 之后加入了新公司，然后正好赶上一个很紧急的项目，忙成狗，因此好久没更新文章了。 不过，我又回来啦！ 前言 --- 自动化测试，我们将使用karma和nightmare，内容会包括： 1. 单元测试 2. e2e测试（放下一篇文章） 其实，单元测试一般用在写公共包的时候，比如通用的js函数库，通用的UI组件库。基本不太会在做业务项目的时候还使用单元测试。 然后，e2e测试的话，那其实往往是测试工程师需要做的，往往使用selenium。 那难道前端就不需要学测试了吗？ 答案肯定是否定的，不然我写个毛...... vue的项目就用了单元测试和e2e。 基于vue的UI组件库，比如：饿了么的element、滴滴的cube-ui、有赞的vant等都有单元测试（咩有e2e，因为没必要）。 滴滴的话，我问了下黄轶大佬，他们项目前端自动化测试是用了单元测试和e2e的。 总之，两种都是由应用场景的，e2e虽然用的不多，或者说有时候不是前端自动化的范畴，但是其实做起来很简单，学会准没错！ 一、单元测试 --- ### 安装karma ```shell npm install karma --save-dev npm...
前言 --- 相信很多人都用过`vue-cli`或`create-react-app`或者类似的脚手架。 脚手架方便我们复制，粘贴，或者clone代码库，而且还可以更具用户的选择，引入用户所需要的插件。 脚手架往往搭配着早已设计好了架构的项目，然后按需进行拷贝。 Yeoman --- ### 介绍 >官网介绍: The web's scaffolding tool for modern webapps. yeoman是一款来做脚手架的工具，我们借助它，就能很容易地开发出自己的脚手架了。 yeoman具体的使用，本文不会介绍太多，官网的文档差不多就够了，我也会在文章末尾放上自己搜集的一些参考资料，同学们自己看看就好了。 ### 安装 安装yeoman: `npm install -g yo` generator --- generator其实就是一个node module，即npm。yeoman根据我们写的generator来执行我们写的构建代码。（对怎么自己选一个npm包不熟悉的同学，可以[戳这里>>](https://github.com/CodeLittlePrince/blog/issues/8)）...
前言 --- vuex想必不需要我介绍很多了，这一节主要是为了填补项目没有引入vuex的问题，之后做完脚手架可以选择是否使用vuex。 因为vuex用的实在是很普遍，就不介绍细节了，我们直接搭项目。 新建文件 --- 在`app`目录新建文件夹`store`： ```shell app/store ├── README.md ├── actions.js ├── getters.js ├── index.js ├── mutation-types.js ├── mutations.js └── state.js ``` 上代码 --- 不多说，直接上代码吧。 `actions.js`: ```shell import...
前言 --- #### 吐槽 e2e测试在前端测试中，也许是最不被看重的一项吧。 小公司就不说了，即使是大厂，也极少有e2e测试。因为它需要花费的精力，相比得到的回报而言，可以说是相差悬殊，说白了，就是吃力不讨好- -|| e2e测试其实就是模拟用户行为，我们得根据业务写各种各样的不同操作。而几乎所有的项目，业务都是会变的。所以，因为业务变了，模拟用户行为也会随之改变。最后，就各种改，即改业务代码，又改测试代码，结果，无端端多出一大堆工作量，而且，很大的可能，下一轮迭代还得改，我上次就是这么死的。 #### 燃鹅 但并不是所有的项目都不适合e2e测试的。比如，一个大项目，已经上线多年了，需求内容等基本都成形了。这种情况，就比较适合上e2e了。 项目大的缺点就是，修改的时候，一不小心就会牵一发而动全身。当年刚初来乍到的时候，就经常不小心改了公共样式，或者公共js，然后导致多个页面发生了变化，从而产生bug。因此，这种时候就很需要e2e测试了。 #### 运用场景 总的来说，e2e的运用场景就是：上线久、业务稳、体量大的项目啦~（千万不要在刚启动或迭代很快的项目上e2e，切记，切记） nightmare --- nightmare是高阶浏览器自动测试库。 #### 对比phantom nightmare相比phantom而言，api更加简洁方便，比如引用的比较多的就是，同样是实现一个向yahoo自动提交关键词并搜索的功能： 1. PhantomJS实现 ```js phantom.create(function (ph) { ph.createPage(function (page) {...
前言 --- 弄完了前后端分离，我们自然想打包发布项目了。 不多说，就让我们来看看吧。 开发 --- 直接上代码： ```js const webpack = require('webpack') const path = require('path') const ExtractTextPlugin = require('extract-text-webpack-plugin') const webpackConfigBase = require('./webpack.config.js') const HtmlWebpackPlugin = require('html-webpack-plugin') const CleanWebpackPlugin...
前言 --- 上一篇我们遇到'少年，是不是忘了npm run mock?'的警告，这一篇我们就来解决这个问题。 开发 --- ### 一、安装包 安装koa和一系列的包（我们用的是koa v2）： ```shell koa koa-bodyparser koa-router boom nodemon mockjs ``` 解释说明一下（知道的同学可以忽略）: 名称 | 作用 --- | --- koa | 我们都知道Node.js有HTTP模块，来处理HTTP请求，koa基于Node做了很多方便的接口让我们更顺畅地处理HTTP，比如，接收、解析、响应。 koa-router...
前言 --- 想想也已经做过不少架构的项目了，有基于vue，基于react，基于thinkPHP，基于laravel的。 做多了，也就对现有的架构有各种想法，有好的，有坏的，总之，用起来还是不爽。vue-cli虽然可以很快地构建并使用，尤其是vue-cli v3.0，把webpack都封进`@vue/cli`的sdk里了，用起来更加干净、简洁。 但是，对于爱折腾的我们，好吧，开个玩笑。重来，但是，对于页面的优化，还有项目的架构，我们不得不做多多少少的修改。 好了，介绍完毕，接下来，我就从零开始，一步一步建起前后端完全分离的前端架构了。 步骤 --- 由于要介绍的很多，全写在一篇里，有些太长了。 所以，我会分为： 1. 创建开发环境下的webpack配置文件 2. 配置eslint、babel、postcss 3. 创建项目文件、目录架构 4. 通过koa实现本地数据接口模拟 5. 创建发布环境下的webpack配置文件 6. 创建测试环境下的webpack配置文件、以及测试用例 （TODO） 7. 自动初始化构建项目（TODO） 这七篇来分别介绍。 开发 --- ###...
前言 --- 这一篇，我们将接着上篇来完成创建项目文件、目录结构。 回顾 --- 先回顾一下现在项目有哪些东西了： ```shell . ├── app │ ├── app.vue │ ├── common │ │ ├── img │ │ ├── js │ │ └── scss │ ├──...
前言 --- 这一篇，我们将接着上篇来完成配置eslint、babel、postcss。 开发 --- ### 一、配置eslint 我们采用`eslint --init`的方式来创建eslintrc.js。 对了，前提我们需要全局安装eslint：`npm i -g eslint`。 安装完全局eslint以后，我们在项目根目录使用`eslint --init`，我选择自定义的方式来规定eslint规则： ```shell ➜ vue-construct git:(master) ✗ eslint --init ? How would you like to configure ESLint?...
为什么要做dynamic import？ --- dynamic import不知道为什么有很多叫法，什么按需加载，懒加载，Code Splitting，代码分页等。 总之，就是在SPA，把JS代码分成N个页面份数的文件，不在用户刚进来就全部引入，而是等用户跳转路由的时候，再加载对应的JS文件。 这样做的好处就是加速首屏显示速度，同时也减少了资源的浪费。 为什么选择 webpack 3? --- - 更高的性能 - 有scope hosting功能，不再需要rollup来处理代码冗余 - 可与react-router结合，更优雅的做dynamic import - 最重要的一点是，我正经学webpack的时候3已结出了- - 完整的 react spa 项目地址 --- [GitHub项目地址][1] 这个一个完整的项目，这节相关的内容可在router/routerMap.jsx中找到。...