BrandonX
BrandonX
> Please make sure all the requirements are satisfied, otherwise the PR could be closed without further notice. ## Checklist - [x] Title as described. - [x] Make sure you...
Add an unit test for webpack v2
写的不错，但是样式适配方面写的还不够。
## 前言 **为什么我们需要测试？** > 让产品可以快速迭代，同时还能保持高质量 -- [阮一峰 持续集成是什么？](http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html?utm_source=tuicool&utm_medium=referral) 对于一些相对稳定的系统级别页面，自动化测试在提高测试的效率的方面起到非常重要的作用。前端的自动化测试主要包括：浏览器测试和单元测试。Vue官方脚手架自带自动化测试配置，并帮助你完成对组件，函数等的自动化测试。 **什么是持续集成？它和持续部署有什么区别？** 代码集成到主分支需要经过一系列的自动化测试，当测试都通过之后，方可执行自动化部署，否则不能完成集成。这说明了自动化测试的重要性，我们不能等测试工程师去发现问题。 在Vue脚手架当中，Karma和NightWatch分别对应着单元测试和e2e测试。单元测试更多是面向JS功能逻辑的检验，而NightWatch更多是面对业务逻辑的检验。 ## 单元测试 代码的单元测试主要针对某些核心功能的某些函数进行测试。vue官方推荐是使用karma，mocha和chai等。karma并不是一个测试框架，也不是一个断言库。它可以运行HTTP Server，运行HTML文件在你喜欢的测试框架上。不仅仅只是运行测试，还可以计算测试的覆盖率。mocha是测试框架，专门实现各个单元划分测试。chai是典型的断言库。  ```sh npm run unit # 运行单元测试 ``` #### Karma [Karma](https://github.com/karma-runner/karma)是一个专门的测试运行器（runner），它不是一个测试框架框架，也不是以一个断言库。Karma兼容[Jasmine](https://github.com/karma-runner/karma-jasmine)，[Mocha](https://github.com/karma-runner/karma-mocha)和[QUnit](https://github.com/karma-runner/karma-qunit)，可以集成mocha，webpack等功能，成为以Karma为平台的单元测试，官方选择的事mocha的测试框架和chai的断言库。它拥有一些测试插件： - [karma-webpack](https://github.com/webpack-contrib/karma-webpack) 用webpack预处理文件...
我记得去年很多人看了我《用Webpack构建Vue》一篇文章，但是因为webpack和vue升级速度很快，那文章很快就过时了。学习vue最好的教材莫过于[vue-cli](https://github.com/vuejs/vue-cli)直接生成的单页面项目。可惜的是它不过是一个单页面的项目，在我们的实际生产环境中，往往都是较为分散的页面，为的是保证项目的解耦。 > [饿了么的 PWA 升级实践](https://huangxuan.me/2017/07/12/upgrading-eleme-to-pwa/)正讲到饿了么的超大型SPA如何解耦成MPA的过程。 ## 多页面脚手架 > github源码在此，记得点星: https://github.com/brandonxiang/mpa #### 特点 - 多个入口 - DllReferencePlugin 利用控制多页面常用包 - CommonsChunkPlugin 控制多页面的公用包 - ejs模版语言控制html - --nomap 命令控制sourceMap - whitelist 控制专门打包 #### 使用方法...
AlloyTeam Conf是一个干货非常集中的前端大会。就前端的技术，我分享一下前端大会的内容，谈谈自己的想法。 ## 面向亿万级用户的Web同构直出 直出技术也就是传说中的服务端渲染“SSR”技术，Web首屏页面的加载速度能得到极大提升。AlloyTeam采用的是React技术栈同构直出，我们采用Vue技术栈的同构直出。 主讲人李强用实战经历说明了手Q在高访问量的直出表现，他说道，直出其实减轻了浏览器的负担，但是增加了服务器的负担，大概是以前的5倍。这个在生产环境实现起来事有难度的。 #### 实现原理  SSR技术说白了就是在服务端和浏览器端各有一个入口，共用一份代码。服务端会把内容拼接好，缓存起来，提高首屏效率。代码的差异性需要处理，例如生命周期不同。 > 由于没有动态更新，所有的生命周期钩子函数中，只有 beforeCreate 和 created 会在服务器端渲染(SSR)过程中被调用。这就是说任何其他生命周期钩子函数中的代码（例如 beforeMount 或 mounted），只会在客户端执行。 所以有些浏览器相关的内容要在 mounted 底下写。简而言之，SSR的vue项目需要注意的点和普通项目不同，迁移会带来成本。 因为涉及到更多的服务端，SSR会带来更大的服务器宕机的风险。腾讯的做法事监测服务器的负载，负载过高的情况有柔错处理，也就是服务器会指向“Plan B”非SSR的页面。这样，也就是你一套代码要打包出两套页面（SSR和非SSR）。 ## 大型Web项目可用性提升 - 零脚本错误的实战 脚本错误对于前端开发者一点都不陌生。测试工程师手上机型有限，一旦发生脚本错误，轻则影响页面的一些功能，重则直接导致页面白屏。大众用户处在不同的网络情况、不同的浏览器。也有可能是后台改了数据类型等，更新数据出错都有可能反应在前端。 高效的错误收集分类是非常重要，有这么一个平台可以收集到很多数据，从而进一步优化整个页面，这是一个良性的反馈。[Sentry](https://github.com/getsentry/sentry)是有名的错误上报平台，服务端是python写的，提供很多款语言的SDK，进行定制化的错误分类分析。...
## 前言 **为什么不用ID标识符** 主要考虑到样式重用性以及与页面的耦合性。ID本来就是唯一的而且权值那么大，还不如写在行内样式。 ``` #button { text-decoration: underline; } ``` **为什么不用大于三层嵌套选择器** 嵌套选择器增加了代码耦合，使重用变得不可能，过多的嵌套会导致显示性能下降。简洁的选择器不仅可以减少css文件大小，提高页面的加载性能，让浏览器解析时也会更加高效。同时也会提高开发人员的开发效率，降低了维护成本。子代选择器不好的地方还在于，如果层次关系过长，逻辑不清晰，非常不利于维护。 css的匹配原理**不是从左到右的，而是从右到左的**，从右边开始匹配是为了尽早过滤掉一些无关的样式规则和元素。 ```css .button_hovered .button__text { text-decoration: underline; } ``` **为什么不用组合选择器** 组合选择器的耦合性更强，而且可维护性更加差。 ```css .button.button_theme_islands { text-decoration: underline; }...
>源码github地址在此，记得点星： https://github.com/brandonxiang/example-mocha 单元测试是好代码必经的一步。在python中我使用过内置库unittest，相对来说，比较简单。如果你在知乎上了解到thoughtwork这公司，你会清楚地认识到测试的重要性，thoughtworks非常推崇TDD，也就是先写测试再开始编码，这样看似效率较低，但是却有效提高了代码质量，也很好满足你对需求的测试。单元测试会涉及到两个概念，BDD和TDD。 - BDD **行为驱动开发（Behavior Driven Development）**根据用户的行为需求去指导开发流程 - TDD **测试驱动开发（Test-Driven Development）**先编写单元测试用例代码，测试代码确定需要编写什么产品代码 Javascript的测试框架非常多，参考[在Node.js上用什么测试框架好](https://www.zhihu.com/question/20075367)，在Node.js中，mocha应该是测试框架中的首选。在这里，主要介绍mocha，should.js和chai.js。 ## mocha [mocha](https://github.com/mochajs/mocha)本身只是一个单元测试框架，可以兼容第三方断言库。 - [should.js](https://github.com/shouldjs/should.js) - [expect.js](https://github.com/LearnBoost/expect.js) - [chai](http://chaijs.com/) - [better-assert](https://github.com/visionmedia/better-assert) - [unexpected](http://unexpected.js.org/) ### 使用 参考[brandonxiang/interpolator](https://github.com/brandonxiang/interpolator)中的测试用例。 `describe`用于描述你需要单元测试的对象，内嵌几层，把整个过程详细描述。...
撰稿人：项伟平 我最近也经常面试外包同事。面试的时候，总会有个问题，“你说一下性能优化的手段”。百分之八十的人都会说，压缩js和css之类的。显然这些都是必须做的，而且已经根本不是主要的性能优化的关键点。如果你只会说这些，只能说明你是个过时的前端工程师。 性能优化过程中，我们需要面对的更多是DMS解析过程，服务器缓存和浏览器缓存机制。 ## gzip压缩 在所有的web前端项目，静态资源基本都放在cdn上，gzip的压缩是非常必要的，它直接改变了js文件的大小，减少两到三倍。 参考[加速nginx: 开启gzip和缓存](https://www.darrenfang.com/2015/01/setting-up-http-cache-and-gzip-with-nginx/)，nginx的gzip配置非常简单，在你对应的域名底下，添加下面的配置，重启服务即可。`gzip_comp_level`的值大于2的时候并不明显，建议设置在1或者2之间。 ```bash # 开启gzip gzip on; # 启用gzip压缩的最小文件，小于设置值的文件将不会压缩 gzip_min_length 1k; # gzip 压缩级别，1-10，数字越大压缩的越好，也越占用CPU时间，后面会有详细说明 gzip_comp_level 2; # 进行压缩的文件类型。javascript有多种形式。其中的值可以在 mime.types 文件中找到。 gzip_types text/plain application/javascript application/x-javascript...