前端开发的变化

随着 Node.js 的兴起，越来越多的人使用 JavaScript 开发后台的一些应用。同时促进了模块化开发和包管理生态系统的发展。所以目前在国外，越来越多的人使用 CommonJS 规范来处理模块加载。但是为了能让代码在浏览器上能正常运行，我们需要在上线前，将相互依赖的模块整合打包到一个文件，这样就可以避免 CommonJS 同步加载的缺陷。

Browserify 的热捧

最初在寻找打包工具时，发现大家都选择了 Browserify 这款打包工具。所以一开始我也毫不犹豫地选择了它。后来在使用过程中发现，Browserify 只能将所有文件打包成一个文件，如果需要分开打包，需要手动配置。那这样的打包方式，只适用如下一些场景：

• 小规模网站，即代码量小
• 很少更新网站，意味着业务代码很少更新
• 不太关心第一次页面加载时长

这显然不太适应大部分网站的使用场景。

2. 从 Browserify 叛逃到 Webpack

在实际使用过程中，我考虑到了一些代码合并优化的问题，比如是否可以将一些第三方库单独打包？不需要将所有代码打包到一个文件夹。是否可以分页面打包相关的代码？这些问题 Browserify 都不予理睬。后来又通过一些博文了解到 Webpack 这款打包工具。
在查阅官方文档和前人研究成果后，才发现 Webpack 是一款很强大的打包工具。它除了能能解决上面提到的几个问题，同时还支持其它一些特色功能。下面我来一一介绍一下这些功能：

Code Splitting

1. 打包时排出某个文件
   • 当第三方库占整个打包文件的大小比例比较大，比如 20% 以上「When your vendors reaches a certain percentage of your total app bundle. Like 20% and up」
   • 经常会更新网站「You will do quite a few updates to your application」
   • 不太关心第一次页面加载时长，但是当你更新网站时，你关心优化回访用户的使用体验「You are not too concerned about perceived initial loading time, but you do have returning users and care about optimizing the experience when you do updates to the application」
   • 用户是通过手机访问的「Users are on mobile」
2. 分多个入口打包文件，并提取多个合并文件中的共同文件
   • 网站有多个独立的体验部分，但是它们共享大部分代码「You have an application with multiple isolated user experiences, but they share a lot of code」
   • 有一个使用较少组件的移动版本「You have a mobile version using less components」
   • 是一个典型的用户前台和后台应用网站，你不想在普通用户访问时加载后台的代码「You have a typical user/admin application where you do not want to load all the admin code for a normal user」
3. 在某个文件中设置异步加载某些模块
   • 网站规模很大，用户可以访问不同的部分「You have a relatively big application where users can visit different parts of it」
   • 很在意第一次页面渲染时间「You do care a lot about initial render time」

以上这些功能覆盖了大部分的使用场景。

静态资源模块化加载

我们可以把一些静态资源「Img、CSS、Font、HTML Template 等」组合打包到一个文件，实现组件化开发。

编译文件

目前我们习惯用 SCSS 或 LESS 来写 CSS，用 CoffeeScript 写 JavaScript，还有 React 的 JSX 语法。
Webpack 提供了 sass-loader，coffee-loader, jsx-loader 等插件，当加载这些格式的模块文件时，会先执行编译，最后把编译结果引入指定文件。

插件

Webpack 提供了很多插件，比如 UglifyJsPlugin，用来压缩 JS。更多插件可以看这里

Sever 服务并提供类似 Liveload 功能

Webpack 能开启一个本地 Sever，同时监听各打包文件，当某个文件发生变动时，会重新打包。同时利用它提供的 Hot Mode 功能，能实现类似 Liveload 效果，具体表现如下：

• CSS 变化时，不用刷新页面就能更新内容
• JSX Component 变化时，不用刷新页面就能更新内容
• 某个 JS 文件变动时，会自动重新打包并刷新页面

3. 结语

除了这些，Webpack 还提供了一些高级的功能。具体可以查看它的官网文档。但是目前来说，Webpack 不是 Gulp 的替代品，它们俩可以互相配合，发挥你的想象力，来提高前端开发的效率吧。

参考资料：

1. Webpack doc
2. React-webpack-cookbook
3. Webpack-how-to
4. Webpack 入门指迷

前提说明：本篇是在学习Backbone的时候，实战练习写了一个 TodoMVC，并在原有代码上基础做了部分改进工作。

主要的改进

• 引入模块开发并使用CommonJS规范
• 使用Webpack工具加载和打包模块
• 将 HTML 模板独立成单一模块文件，同时让模块 JS 文件加载对应的 HTML 模板文件
• 细化了View层的颗粒度，将 View 拆解成：AppView、FooterView、TodoView、TodoListView
• 优化了 View 中render方法监听的事件类型，防止当Model或Collection发生一次变化时，View 多次重复渲染。「原例子中简单监听了all事件」

TodoMVC 架构分析

数据层

1. Todo Model
   • 存储每一个 Todo Item 的标题和是否完成状态
   • 有一个业务逻辑方法：改变是否完成状态
2. Todos Collection
   • 是一组 Todo Model 的集合
   • 负责 Todo 列表的排序
   • 负责过滤 Todo 列表中的数据「过滤剩余和完成的 Todo Item」

View 层

尽可能最小粒度地划分 View，即保证每个独立的 View 对应一个 Model 或 Collection。复杂的 View 由简单的 View 组合而成。这样可以提高开发灵活性，也有利于后期维度。
这种细分 View 的方式可以理解为：

1. view-a1 + view-a2 = view-a
2. view-b1 + view-b2 + view-b3 + view-b4 = view-b
3. view-a + view-b + view-c = view-d

这种划分的规则:

• 每一个最小单位的 View 都只负责处理自身的内容
• 由其它子 View 组合而成的 View 则负责统筹更小单位的 View「通常父层级的 View 负责创建、显示、隐藏或删除子级别 View」
  • View 与 View 之间的通信，则依靠 Model 或 Collection 这个中间体「比如用户操作某个 View1 而影响另外一个 View2，代码实现上是通过修改 View2 对应的数据层来间接刷新 View2」

本次 TodoMVC 中对 View 的细分处理如下：

1. AppView

   • 负责组合所有 APP 内的子 View「判断是否需要增加、显示或隐藏某个组件 View」

     initialize: function () {
     
         // 新建 footer 视图
         app.footerView = new FooterView({
             collection: app.todos
         });
     
         // 新建 todolist 视图
         app.todoListView = new TodoListView({
             collection: app.todos
         });
     },
     
     render           : function () {
         this.renderMain();
         this.renderFooter();
     },
     
     //渲染 main 部分视图
     renderMain       : function () {
         if (app.todos.length) {
             this.$list.append(app.todoListView.el);
             this.$main.show();
     
             // 设置批量操作按钮显示状态
             this.toggleCheck();
         } else {
             this.$main.hide();
         }
     },
     
     // 渲染 footer 部分视图
     renderFooter     : function () {
         if (app.todos.length) {
             this.$footer.append(app.footerView.el);
             this.$footer.show();
         } else {
             this.$footer.hide();
         }
     },
     

2. TodoView
   • 负责每一个 Todo Item 的 View
3. TodoListView
   • 负责一组 Todo Items 的 View
4. FooterView
   • 负责 Footer 部分的 View

关联数据层和 View 层

1. TodoView + Todo Model

   • 将 TodoView 的方法绑定到对应 Todo Model 的事件中

     initialize: function () {
         this.listenTo(this.model, {
             'change' : this.render,
             'destroy': this.remove,
             'visible': this.toggleVisible
         });
     
         this.render();
     },
     

   • 利用 Todo Model 的数据渲染 TodoView 的模板

     var itemTpl = require('../../template/item-tpl.ejs');
     var TodoView = Backbone.View.extend({
         template: itemTpl,
         render       : function () {
             ...
     
             var tmpl = this.template(this.model.toJSON());
             this.$el.html(tmpl);
     
             ...
             return this;
         },
         ...
     )};
     

   • Todo View 中一些方法可以修改 Model 数据

     // 改变 Model complete 状态
     toggleCompleted: function () {
         this.model.toggleCompleted();
     },
     
     // 清除 Model
     clear         : function () {
         this.model.destroy();
     },
     

2. TodoListView + Todos Collection

   • 将 TodoListView 的方法绑定到对应 Todos Collection 的事件中

     initialize: function () {
         this.listenTo(this.collection, {
             'add'             : this.addOne,
             'reset'           : this.addAll,
             'change:completed': this.filterOne,
             'filter'          : this.filterAll,
             'destroy'         : this.render
         });
     },
     

   • TodoListView 可以访问 Todos Collection, 从而间接访问其中的 Model

     filterOne : function (todo) {
         todo.trigger('visible');
     },
     filterAll : function () {
         this.collection.each(this.filterOne, this);
     }
     

3. FooterView + Todos Collection

   • 将 FooterView 的方法绑定到对应 Todos Collection 的事件中

     initialize: function () {
         this.listenTo(this.collection, 'add remove reset change:completed', this.render);
         this.listenTo(this.collection, 'filter', this.setSelectedTab);
     },
     

   • FooterView 可以访问 Todos Collection

     // 清除已经完成的 todoitem
     clearCompleted: function () {
         _.invoke(this.collection.completed(), 'destroy');
     }
     

   • 利用 Todos Collection 的数据渲染 FooterView

     var footerTpl = require('../../template/footer-tpl.ejs');
     
     var FooterView = Backbone.View.extend({
         template: footerTpl,
         ...
         render        : function () {
     
             // 提取当前所绑定的 collection 数据的状态
             var remaining = this.collection.where({
                 completed: false
             }).length;
             var completed = this.collection.where({
                 completed: true
             }).length;
     
             // 利用获取的 collection 数据渲染模板
             var footerView = this.template({
                 remaining: remaining,
                 completed: completed
             });
     
             this.$el.html(footerView);
     
             ...
         },
         ...
     });    
     

前提说明：
本文通过对比一些主流 JavaScript Style Guide, 摘录了一些值得借鉴的语法书写方式，以提高程序执行性能。而格式问题「Formatting: space, newline, etc」暂且被忽略了，因为一般可以通过 IDE 编辑器设置处理，写的时候可以按照自己的习惯来，通过编辑器格式配置方式以保持和团队风格统一，常见格式建议可查看参考资料。

变量声明「Variable Declaration」

Object

• 使用 Literal declaration

  var item = {};
  

• 使用同义词替换保留字

  // bad
  var superman = {
    class: 'alien'
  };
  
  // bad
  var superman = {
    klass: 'alien'
  };
  
  // good
  var superman = {
    type: 'alien'
  };
  

Array

var items = [];

Function

• 如果在non-function block(if, while, etc)，声明一个函数，需要把函数赋值给一个变量。「ECMA-262 中定义a list of statements为a block」

  // bad
  if (currentUser) {
      function test() {
      console.log('Nope.');
      }
  }
  
  // good
  var test;
  if (currentUser) {
    test = function test() {
      console.log('Yup.');
    };
  }
  

• 函数参数中不要使用arguments保留字「因为会覆盖 function scope 中的 arguments」

关于声明提升「Hoisting」

• 变量声明会被提前，但是赋值不会

• 函数声明时，函数名和函数体都会被提前

  function example() {
  
      // => Flying
        superPower(); 
  
        function superPower() {
          console.log('Flying');
        }
  }
  

类型检查「Type Checking 」

实际类型检测「Actual Types Checking」

Types: String、Number、Boolean、Object 类型检查

// 其实 typeof 返回值一定是一个字符串，这里没必要使用 ===，即使用 == 即可
typeof variable == "Types"

Array

Array.isArray(arrayLikeObject)

Node

// nodeType 返回值一定是 number，这里没必要使用 ===，即使用 == 即可
elem.nodeType == 1

null

// 注意：typeof null 返回的是 “object”
variable === null

undefined

// 1. Global Variable
// 这里 typeof 返回值也肯定是字符串，所以用 == 即可
typeof variable == "undefined"

// 2. Local Variable
variable === undefined

null or undefined

// undefined 值可能被重写
variable == null

类型强制转换「Coerced Types」

类型转换部分语法原理，可参考这篇文章：Truth, Equality and JavaScript

var number = 1,
 string = "1",
 bool = false;

 // "1"
 number + "";

 // 1
 +string;    

 // 0
 +bool; 

 // "false"
 bool + "";

 // "false"     
 !string;

 // "true"
 !!number;

条件判断「Conditional Evaluation」

Booleans, Truthies & Falsies 判断

// Booleans:
true, false

// Truthy:
"foo", 1, Object

// Falsy:
"", 0, null, undefined, NaN, void 0

判断数组是否为空

// 当数组不为空时
if (array.length) ...

// 当数组为空时
if (!array.length) ...

判断字符串是否为空

// 当字符串不为空时
if (string) ...

// 当字符串为空时
if (!string) ...

判断引用是否为空「evaluating a reference」

// 当引用不为空时
if (foo) ...

// 当引用为空时
if (!foo) ...

// 除去匹配: 0, "", null, undefined, NaN 情况，只匹配 boolean false
if (foo === false) ...

// 只匹配 null or undefined, 因为 null == undefined
if (foo == null) ...

判断数组中是否存在某元素

array.indexOf( "a" ) >= 0

常见操作优化

Array 操作

• 使用 Array.push 而不是直接赋值
• 使用 Array.slice 拷贝数组
• 使用 Array.prototype.slice.call(arrayLikeObject) 将 array-like 对象转换为数组

String 操作

• 使用 Array.join 拼接字符串

• 处理长字符串跨行时，用 “+” 拼接字符串

  // bad
  var errorMessage = 'This is a super long error that was thrown because of Batman. When you stop to think about how Batman had anything to do with this, you would get nowhere fast.';
  
  // bad
  var errorMessage = 'This is a super long error that was thrown because \
  of Batman. When you stop to think about how Batman had anything to do \
  with this, you would get nowhere \
  fast.';
  
  // good
  var errorMessage = 'This is a super long error that was thrown because ' +
    'of Batman. When you stop to think about how Batman had anything to do ' +
    'with this, you would get nowhere fast.';
  

Object 操作

• 使用.读取字符串属性
• 使用[]读取变量数量

参考资料：

1. Principles of Writing Consistent, Idiomatic JavaScript
2. Airbnb JavaScript Style Guide
3. Truth, Equality and JavaScript

当两个元素位置互相堆叠在一起时，CSS 样式是如何决定哪个元素显示在前，哪个元素显示在后的呢？

为了解决这个问题，在左右、上下的布局基础上，CSS 2.1 引入了第三维度Z 轴的概念。CSS 将所有元素都被纳入一个Stacking Context中，根据某种规则控制元素堆叠的优先顺序，下面主要详细介绍一下这种规则。

Stacking Context 介绍

CSS 2.1 Spec 对Stacking Context的描述：

The order in which the rendering tree is painted onto the canvas is described in terms of stacking contexts.

我对这句话的理解是：Stacking Context有着一套规范元素堆叠顺序的规则。在渲染页面时，根据这套顺序规则依次在 Z 轴上显示不同元素。

Stacking Context 的特性

• 每个文档布局中存在多个 Stacking Context。而产生一个新的 Stacking Context 是有条件的「详见下文」
• 在每个Stacking Context中可以嵌套其它的Stacking Context
• 每个Stacking Context中的元素位置和同级的Stacking Context中元素位置的顺序是互相独立的
• 每个Stacking Context是自包含的，即当父元素形成一个Stacking Context「此时作为后代元素的Parent Stacking Context」，所有内部后代元素的堆叠顺序都仅限在Parent Stacking Context比较

  Stacking Context 内部元素排列顺序规则

  按抵部->顶部顺序，可以抽象成七层布局：

归属于不同 Stacking Context 的元素顺序比较

上面介绍的堆叠顺序规则只用于比较同属于一个Parent Stacking Context的元素堆叠顺序。如果两个元素属于两个不同的Parent Stacking Context，那么它俩的顺序是由Parent Stacking Context的顺序决定的。

这句话说的有点绕，我们用图例来解释：

从图例中可以看到，DIV #2.1元素位置在DIV #1.1和DIV #1.2之下，尽管它的z-index值为 100。产生这个现象的原因就是因为DIV #2.1和DIV #1.1不在同一个Parent Stacking Context。所以此时需要找到DIV #2.1的Parent Stacking Context，即为DIV #2，此时比较DIV #2和DIV #1.1的堆叠顺序，因为DIV #2的z-index值为 1，所以它在DIV #1.1元素的下方，同时DIV #2.1的位置顺序受限于DIV #2，最后的排布顺序就如图所示。

图例解释说明：

• DIV #n，#n.n，#n.n.n 表示互为父-子元素关系，具体HTML结构层次：

• Body
  • DIV #1
    • DIV #1.1
      • DIV #1.2
  • DIV #2

    * DIV #2.1
      * DIV #2.1.1
       * DIV #2.1.2
    

• 绿色背景表示根元素「即<html>」产生的Stacking Context
• 颜色相同的元素表示它们同属于一个Parent Stacking Context，Stacking Context层次关系：

• Root
  • DIV #1
  • DIV #1.1
  • DIV #1.2
  • DIV #2
    • DIV #2.1
      • DIV 2.1.1
      • DIV 2.1.2

既然元素处于哪个Parent Stacking Context也会影响元素显示顺序，那么我们来看看元素的Parent Stacking Context是如何产生的：

最外层的Stacking Context是根元素产生的，那么我们可以理解为它是所有元素的Parent Stacking Context。但当有新的Stacking Context产生时，这个新Stacking Context就是所有后代元素的Parent Stacking Context。以此类推，每当父元素产生一个新Stacking Context，就给后代元素提供了一个Parent Stacking Context。

产生新 Stacking Context 的条件

• Root element「可以理解为第一个Stacking Context，用来包含其它的Stacking Context」
• Positioned元素的z-index值不是auto
• 元素的Opacity值小于 1「可以看作是给普通元素增加了Position属性，且z-index值为 0「详细可见 CSS Spec 2.1」
• Chrome 22+ 和 Mobile WebKit,z-index值为auto的fixed position元素

Positioned 元素堆叠顺序规则

上面介绍了每一个Stacking Context内部元素的堆叠顺序，这里进一步详细介绍Positioned元素的堆叠顺序。

z-index 的作用

Positioned元素的堆叠顺序是由z-index决定的。z-index有2个作用：

1. 决定Positioned元素的Stack Level「可以理解为堆叠优先级，Stack Level值为整数，值大的放在上层」
2. 决定是否形成一个新的Stacking Context

z-index 属性值

z-index 有两个属性值：<integer>和<auto>「注：只有Positioned元素的Z-index值才有效」。

• <integer>：当Z-index设置了一个整数「负整数，零，正整数」时，Positioned元素就产生了一个新的Stacking Context，同时这个整数代表了当前元素的Stack Level
• <auto>：该值说明当前元素的Stack Level值为 0。但此时并没有产生新的Stacking Context，除非这个元素是个根元素「注：这里可以看出z-index = auto和z-index = 0的区别」

总结

1. 任意一个元素都归属一个Stacking Context，Stacking Context可以互相嵌套，从而形成一个Stacking Context层级体系。「Root element是一个初始的Stacking Context，它包裹了其它的Stacking Context」
2. 在每一个Stacking Context内部，有特定堆叠优先级规则决定不同类型元素的堆叠顺序「Positioned元素的堆叠顺序由z-index值决定」
3. 当两个元素归属于不同的Parent Stacking Context时，它们的堆叠顺序互不干扰

参考资料

1. http://www.w3.org/TR/CSS21/zindex.html
2. http://www.w3.org/TR/CSS21/visuren.html#layers
3. http://www.w3.org/TR/css3-color/#transparency
4. http://segmentfault.com/a/1190000000460664
5. http://gbspacing.com/z-index.gb
6. https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Understanding_z_index