前言

随着 React/Redux 的火热，函数式编程也逐渐被带入了前端的应用领域，甚至还诞生了 elm、ClojureScript 等基于 JavaScript 的函数式语言。熟练掌握这节课的内容，对后续学习函数式编程会有一定帮助。

1. 高阶函数

高阶函数也是函数式编程中的一个概念，使用范围比较广泛。在现在很火的 React 中，高阶组件就是基于高阶函数发展而来。
先看一下高阶函数的定义：

高阶函数，又称算子(运算符)或泛函，包含多于一个箭头的函数。
在数学和计算机科学中，高阶函数是至少满足下列一个条件的函数:

1. 接受一个或多个函数作为输入
2. 输出一个函数

举一个简单的例子：

const add = function(x, y, f) {
    return f(x) + f(y);
}

这个 add 函数就是一个高阶函数，它接收了另一个 f 函数。
而在 ES5 中出现的 forEach、map、some、every 等函数也属于高阶函数，他们都接收了一个匿名函数作为参数：

const arr = [1, 2, 3];
const iterator = function(item, index) {
    console.log(item);
}
arr.forEach(iterator);

2. 偏函数

下面是维基百科对偏函数 (Partial application) 的定义：

In computer science, partial application (or partial function application) refers to the process of fixing a number of arguments to a function, producing another function of smaller arity.

翻译一下，意思就是在计算机科学中，部分应用程序（或者部分功能应用程序）是指固定一个函数的一些参数，然后产生另一个更小元的函数。

那么什么是元呢？元就是函数参数的个数，比如带有两个参数的函数被称为二元函数。

偏函数是函数式编程中的一部分，使用偏函数可以冻结那些预先确定的参数来缓存函数参数。在运行的时候，当获得需要的剩余参数后，可以将他们解冻，传递到最终的参数中，从而使用最终确定的所有参数去调用函数。

简单来说就是，把一个函数的某些参数给固定住（也就是设置默认值），返回一个新的函数，调用这个新函数会更简单。

举个比较简单的例子，下面的 sum_add_1 就是一个偏函数。

function sum(a, b) {
    return a + b;
}
// 正确调用
sum(2, 3); // 5
const sum_add_1 = partial(sum, 1);
sum_add_1(2); // 3
sum_add_1(3); // 4

那么怎么实现这个 partial 方法呢？实际上使用原生的 bind 方法就能产生一个偏函数。

const sum_add_1 = sum.bind(null, 1);

可是 bind 函数中一般需要传入上下文给第一个参数，我们这里可以实现一个无关上下文的 partial 函数。
由于 partial 函数执行后返回了一个新的函数，那么它一定是个高阶函数。可以考虑如下实现：

const partial = (func, ...args) => {
    return (...rest) => {
        return func.apply(this, [...args, ...rest])
    }
}

3. 柯里化

在 JS 的函数式编程中，柯里化是一个很重要的概念，这个概念在我们实际开发中也经常会用到。

3.1 定义

函数柯里化的意思就是你可以一次传很多参数给 curry 函数，也可以分多次传递，curry 函数每次都会返回一个函数去处理剩下的参数，一直到返回最后的结果。

这里还是举几个例子来说明一下：

3.2 柯里化求和函数

    // 普通方式
    var add1 = function(a, b, c){
        return a + b + c;
    }
    // 柯里化
    var add2 = function(a) {
        return function(b) {
            return function(c) {
                return a + b + c;
            }
        }
    }

这里每次传入参数都会返回一个新的函数，这样一直执行到最后一次返回 a+b+c 的值。
但是这种实现还是有问题的，这里只有三个参数，如果哪天产品经理告诉我们需要改成100次？我们就重新写100次？这很明显不符合开闭原则，所以我们需要对函数进行一次修改。

var add = function() {
    var _args = [];
    return function() {
        if(arguments.length === 0) {
            return _args.reduce(function(a, b) {
                return a + b;
            })
        }
        [].push.apply(_args, arguments);
        return arguments.callee;
    }
}
var sum = add();
sum(100, 200)(300);
sum(400);
sum(); // 1000

我们通过判断下一次是否传进来参数来决定函数是否运行，如果继续传进了参数，那我们继续把参数都保存起来，等运行的时候全部一次性运行，这样我们就初步完成了一个柯里化的函数。

3.3 通用柯里化函数

这里只是一个求和的函数，如果换成求乘积呢？我们是不是又需要重新写一遍？仔细观察一下我们的 add 函数，如果我们将if里面的代码换成一个函数执行代码，是不是就可以变成一个通用函数了？

var curry = function(fn) {
    var _args = [];
    return function() {
        if(arguments.length === 0) {
            return fn.apply(fn, _args);
        }
        [].push.apply(_args, arguments);
        return arguments.callee;
    }
}
var multi = function() {
    return [].reduce.call(arguments, function(a, b) {
        return a + b;
    })
}
var add = curry(multi);
add(100, 200, 300)(400);
add(1000);
add(); // 2000

在之前的方法上面，我们进行了扩展，这样我们就已经实现了一个比较通用的柯里化函数了。
也许你想问，我不想每次都使用那个丑陋的括号结尾怎么办？

var curry = function(fn) {
	var len = fn.length,
		args = [];
	return function() {
		Array.prototype.push.apply(args, arguments)
		var argsLen = args.length;
		if(argsLen < len) {
			return arguments.callee;
		}
		return fn.apply(fn, args);
	}
}
var add = function(a, b, c) {
	return a + b + c;
}

var adder = curry(add)
adder(1)(2)(3)

这里根据函数 fn 的参数数量进行判断，直到传入的数量等于 fn 函数需要的参数数量才会返回 fn 函数的最终运行结果，和上面那种方法原理其实是一样的，但是这两种方式都太依赖参数数量了。
我在简书还看到别人的另一种递归实现方法，实现思路和我类似。

// 简单实现，参数只能从右到左传递
function createCurry(func, args) {

    var arity = func.length;
    var args = args || [];

    return function() {
        var _args = [].slice.call(arguments);
        [].push.apply(_args, args);

        // 如果参数个数小于最初的func.length，则递归调用，继续收集参数
        if (_args.length < arity) {
            return createCurry.call(this, func, _args);
        }

        // 参数收集完毕，则执行func
        return func.apply(this, _args);
    }
}

这里是对参数个数进行了计算，如果需要无限参数怎么办？比如下面这种场景。

add(1)(2)(3)(2);
add(1, 2, 3, 4, 5);

这里主要有一个知识点，那就是函数的隐式转换，涉及到 toString 和 valueOf 两个方法，如果直接对函数进行计算，那么会先把函数转换为字符串，之后再参与到计算中，利用这两个方法我们可以对函数进行修改。

var num = function() {
}
num.toString = num.valueOf = function() {
	return 10;
}
var anonymousNum = (function() { // 10
	return num;
}())

经过修改，我们的函数最终版是这样的。

var curry = function(fn) {
	var func = function() {
		var _args = [].slice.call(arguments, 0);
		var func1 = function() {
			[].push.apply(_args, arguments)
			return func1;
		}
		func1.toString = func1.valueOf = function() {
			return fn.apply(fn, _args);
		}
		return func1;
	}
	return func;
}
var add = function() {
	return [].reduce.call(arguments, function(a, b) {
		return a + b;
	})
}

var adder = curry(add)
adder(1)(2)(3)

那么我们说了那么多，柯里化究竟有什么用呢？

3.4 预加载

在很多场景下，我们需要的函数参数很可能有一部分一样，这个时候再重复写就比较浪费了，我们提前加载好一部分参数，再传入剩下的参数，这里主要是利用了闭包的特性，通过闭包可以保持着原有的作用域。

var match = curry(function(what, str) {
  return str.match(what);
});

match(/\s+/g, "hello world");
// [ ' ' ]

match(/\s+/g)("hello world");
// [ ' ' ]

var hasSpaces = match(/\s+/g);
// function(x) { return x.match(/\s+/g) }

hasSpaces("hello world");
// [ ' ' ]

hasSpaces("spaceless");
// null

上面例子中，使用 `hasSpaces 函数来保存正则表达式规则，这样可以有效的实现参数的复用。

3.5 动态创建函数

这个其实也是一种惰性函数的**，我们可以提前执行判断条件，通过闭包将其保存在有效的作用域中，来看一种我们平时写代码常见的场景。

 var addEvent = function(el, type, fn, capture) {
     if (window.addEventListener) {
         el.addEventListener(type, function(e) {
             fn.call(el, e);
         }, capture);
     } else if (window.attachEvent) {
         el.attachEvent("on" + type, function(e) {
             fn.call(el, e);
         });
     } 
 };

在这个例子中，我们每次调用 addEvent 的时候都会重新进行if语句进行判断，但是实际上浏览器的条件不可能会变化，你判断一次和判断N次结果都是一样的，所以这个可以将判断条件提前加载。

var addEventHandler = function(){
    if (window.addEventListener) {
        return function(el, sType, fn, capture) {
            el.addEventListener(sType, function(e) {
                fn.call(el, e);
            }, (capture));
        };
    } else if (window.attachEvent) {
        return function(el, sType, fn, capture) {
            el.attachEvent("on" + sType, function(e) {
                fn.call(el, e);
            });
        };
    }
}
var addEvent = addEventHandler();
addEvent(document.body, "click", function() {}, false);
addEvent(document.getElementById("test"), "click", function() {}, false);

但是这样做还是有一种缺点，因为我们无法判断程序中是否使用了这个方法，但是依然不得不在文件顶部定义一下 addEvent，这样其实浪费了资源，这里有一种更好的解决方法。

var addEvent = function(el, sType, fn, capture){
    if (window.addEventListener) {
        addEvent =  function(el, sType, fn, capture) {
            el.addEventListener(sType, function(e) {
                fn.call(el, e);
            }, (capture));
        };
    } else if (window.attachEvent) {
        addEvent = function(el, sType, fn, capture) {
            el.attachEvent("on" + sType, function(e) {
                fn.call(el, e);
            });
        };
    }
}

在 addEvent 函数里面对其重新赋值，这样既解决了每次运行都要判断的问题，又解决了必须在作用域顶部执行一次造成浪费的问题。

4. 反柯里化

上面我们介绍过函数柯里化，从字面意思上来理解，反柯里化恰恰和柯里化相反，是为了扩大适用范围，创建一个应用范围更广的函数。使本来只有特定对象才适用的方法，扩展到更多的对象。
看下面一个例子，我们给函数增加一个反柯里化的方法。

Function.prototype.unCurry = function() {
    const self = this;
    return function() {
        return Function.prototype.call.apply(self, arguments);
    }
}

通过反柯里化方法，甚至可以让对象使用数组的 push 方法：

const obj = {};
const push = Array.prototype.push.unCurry();
push(obj, 1, 2, 3);
console.log(obj); // { 0: 1, 1: 2, 2: 3}

但是直接在函数原型上面修改不太好，这里可以实现一个更加通用的反柯里化方法。

const unCurry= function(fn) {
    return function(target, ...rest) {
        return fn.apply(target, rest);        
    }    
};

使用方法和原来的类似：

const obj = {};
const push = unCurry(Array.prototype.push);
push(obj, 1, 2, 3);
console.log(obj); // { 0: 1, 1: 2, 2: 3}

简单理解，柯里化就是对高阶函数进行降阶处理，而反柯里化增加反过来扩大使用范围。

// 柯里化
function(a)(b) -> function(a)(b)
// 反柯里化
target.func(a, b) -> unCurry(func)(target, a, b)

反柯里化的好处就是将原本只有 target 能使用的方法借了出来，可以给更多对象来使用。
我们在开发中，经常会借用 Object.prototype.toString 来检测一个变量的类型，这也是反柯里化的用法之一。

const num = 1, 
    str = '2', 
    obj = {}, 
    arr = [],
    nul = null;
const toString = unCurry(Object.prototype.toString.call);
toString.call(nul); // "[object Null]"
toString.call(num); // "[object Number]"
toString.call(str); // "[object String]"
toString.call(arr); // "[object Array]"

5. 推荐阅读

1. 高阶函数
2. 偏函数
   
3. Javascript偏函数与柯里化
   

前言

最近在做管理台重构的时候，由于后端没有人力支持，刚哥让我自己用mock数据来模拟接口数据，到时候把方案在组里面分享一下。
于是我调查了现在常用的三种mock方案，最后选择了RAP2来做数据mock。

为什么需要mock？

前后端同时开发的时候，后端接口数据没有出来，甚至接口还没发到测试环境，这个时候前端可以mock接口和假数据，模拟开发；

常见的几种mock方式

1. 代码里面写死mock数据，等接口好了后，改成动态请求接口，但后期修改量太大
2. 本地写好一个json文件模拟数据，通过请求json文件获得数据后渲染到页面
3. 搭建mock服务，定义好请求url和请求字段、响应字段等等，直接请求接口获取模拟数据。

常用的mock方案

1. Easy-mock
2. Rap2
3. yapi

easy-mock

easy-mock 是一个在线模拟后台的数据平台，通过官网注册账户之后，你就可以生成一个在线的API接口，然后通过ajax或者axios就可以访问这个接口了。
Easy-mock允许我们使用mockjs的语法，通过编写模板来生成随机数据实现数据模拟。
mock语法：

生成mock数据：

甚至支持编写函数实现更加灵活的数据mock。
编写函数：

生成mock数据：

mockjs

1. Mockjs语法是由三部分组成，分别是属性名、生成规则和属性值
2. 属性名即字段名，属性名和生成规则之间用竖线 | 分隔。
3. 属性值中可以含有 @占位符。
4. 属性值还指定了最终值的初始值和类型。
   更多mockjs语法请看官网：mockjs语法

rap2

rap2 是一个可视化接口管理工具 通过分析接口结构，动态生成模拟数据，校验真实接口正确性， 围绕接口定义，通过一系列自动化工具提升我们的协作效率。

1. 支持mock.js语法：rap2本身基于mock.js
2. 支持接口管理：可管理url地址，不同模块分类。
3. 支持团队协作：拥有团队仓库
4. 支持历史修改操作查看：可查看接口修改情况，但不支持操作回溯。
   5.接口共享：不需要重复编写接口

查看成员活动：

接口管理：

yapi

yapi是去哪儿团队出品的在线模拟后台的数据平台，它拥有最丰富的界面操作以及最强大的mock定制功能。
相比easy-mock和rap2，yapi的优势在于：

1. 更丰富的界面化操作，甚至不需要编写mockjs语法
2. 支持mockjs规则导入
3. 支持编写脚本运行更复杂的规则
4. 支持数据导入与导出

数据导入与导出：

界面化规则：

支持编写脚本与期望：

在项目中使用

由于这三种mock方案都支持本地部署，所以可以将其部署到内网中。如果不方便进行本地部署，那么也可以直接使用在线服务（yapi的在线服务非常不稳定）。
我们可以在项目中使用nginx或者whistle等进行接口转发，比如将以/mock开头的接口转发到rap2的在线服务上面，这样在项目中可以直接调用rap2的在线服务（注意：yapi的在线服务不支持跨域）。

总结

这三种mock方案，easy-mock和rap2依然需要掌握mockjs的语法，尤其是easy-mock缺少界面化操作，rap2拥有不错的界面操作，但仍需要我们记住部分mockjs语法规则。
而yapi则拥有最为完整的界面，可以让我们摆脱mockjs各种晦涩的语法，完全在界面上填写规则。同时yapi还支持高度定制化脚本，无疑是三种mock服务中功能最强大的一个。

目前的打算还是继续深入前端基础知识，所以打算从polyfill开始做起。

bind函数

bind函数最常见的用法是绑定函数的上下文，比如在setTimeout中的this一般都是指向window，如果我们想改变上下文，这里可以使用bind函数来实现。

var a = 10;
var test = function() {
    console.log(this.a);
}
// 如果直接执行test，最终打印的是10.
var bindTest = test.bind({a: "111"})
bindTest(); // 111

从上面这个例子可以看出来，bind函数改变了test函数中this的指向。
除此之外，bind函数还有两个特殊的用法，一个是柯里化，一个是绑定构造函数无效。

柯里化

bind函数的柯里化其实是不完全的，其实只做了一次柯里化，看过MDN的polyfill实现后也就理解了。

var test = function(b) {
    return this.a + b;
}
// 如果直接执行test，最终打印的是10.
var bindTest1 = test.bind({a: 20});
bindTest1(10); // 30
// 这里的bind是个柯里化的函数
var bindTest2 = test.bind({a: 20}, 10);
bindTest2(); // 30;

构造函数无效

其实准确的来说，bind并不是对构造函数无效，只是对new的时候无效，如果直接执行构造函数，那么还是有效的。

var a = 10;
var Test = function(a) {
    console.log(this.a);
}
var bindTest = Test.bind({a: 20});
bindTest(); // 20
// 在new的时候，Test中的this并没有指向bind中的对象
new bindTest(); // undefined

实现一个bind

我们可以先实现一个简易版本的bind，再不断完善。由于是在函数上调用bind，所以bind方法肯定存在于Function.prototype上面，其次bind函数要有改变上下文的作用，我们想一想，怎么才能改变上下文？没错，就是call和apply方法。

然后还要可以柯里化，还好这里只是简单的柯里化，我们只要在bind中返回一个新的函数，并且将前后两次的参数收集起来就可以做到了。

Function.prototype.bind = function() {
    var args = arguments;
    // 获取到新的上下文
    var context = args[0];
    // 保存当前的函数
    var func = this;
    // 获取其他的参数
    var thisArgs = Array.prototype.slice.call(args, 1);
    var returnFunc = function() {
        // 将两次获取到的参数合并
        Array.prototype.push.apply(thisArgs, arguments)
        // 使用apply改变上下文
        return func.apply(context, thisArgs);
    }
    return returnFunc;
}

这里实现了一个简单的bind函数，可以支持简单的柯里化，也可以改变上下文作用域，但是在new一个构造函数的时候还是会改变上下文。

这里我们需要考虑一下，怎么做才能让在new的时候无效，而其他时候有效？

所以我们需要在returnFunc里面的apply第一个参数进行判断，如果是用new调用构造函数的时候应该传入函数本身，否则才应该传入context，那么该怎么判断是new调用呢？

关于在new一个构造函数的时候，这中间做了什么，建议参考这个问题：在js里面当new了一个对象时，这中间发生了什么？

所以我们很容易得出，由于最终返回的是returnFunc，所以最终是new的这个函数，而在new的过程中，会执行一遍这个函数，所以这个过程中returnFunc里面的this指向new的时候创建的那个对象，而那个新对象指向returnFunc函数。

但是我们希望调用后的结果只是new的func函数，和我们正常new func一样，所以这里猜想，在returnFunc中，一定会将其this传入func函数中执行，这样才能满足这几个条件。

Function.prototype.bind = function() {
    var args = arguments || [];
    var context = args[0];
    var func = this;
    var thisArgs = Array.prototype.slice.call(args, 1);
  	var returnFunc = function() {
      Array.prototype.push.apply(thisArgs, arguments);
      // 最关键的一步，this是new returnFunc中创建的那个新对象，此时将其传给func函数，其实相当于做了new操作最后一步（执行构造函数）
      return func.apply(this instanceof returnFunc ? this : context, thisArgs);
    }
    return returnFunc
}
function foo(c) {
    this.b = 100;
    console.log(c);
    return this.a;
}

var func =  foo.bind({a:1});
var newFunc = new func() // undefined

但是这样还是不够的，如果foo函数原型上面还有更多的方法和属性，这里的newFunc是没法获取到的，因为foo.prototype不在newFunc的原型链上面。
所以这里我们需要做一些改动，由于传入apply的是returnFunc的一个实例（this），所以我们应该让returnFunc继承func函数，最终版是这样的。

Function.prototype.bind = function() {
    var args = arguments || [];
    var context = args[0];
    var func = this;
    var thisArgs = Array.prototype.slice.call(args, 1);
    var returnFunc = function() {
      Array.prototype.push.apply(thisArgs, arguments);
      // 最关键的一步，this是new returnFunc中创建的那个新对象，此时将其传给func函数，其实相当于做了new操作最后一步（执行构造函数）
      return func.apply(this instanceof func ? this : context, thisArgs);
    }
    returnFunc.prototype = new func()
    return returnFunc
}

这样我们就完成了一个bind函数，这与MDN上面的polyfill实现方式大同小异，这里可以参考一下MDN的实现：Function.prototype.bind()

参考链接：
1. MDN：Function.prototype.bind()

2. 手写bind()函数，理解MDN上的标准Polyfill

这是underscore源码剖析系列第五篇，今天来聊一下throttle和debounce两个函数。

throttle节流函数

Javascript中的函数大多数情况下都是用户调用执行的，但是在某些场景下不是用户直接控制的，在这些场景下，函数会被频繁调用，容易造成性能问题。
比如在window.onresize事件和window.onScroll事件中，由于用户可以不断地触发，这会导致函数短时间内频繁调用，如果函数中有复杂的计算，很容易就造成性能的问题。
这些场景下最主要的问题是触发频率太高，1s内可以触发数次，但是大多数情况下我们并不需要那么高的触发频率，可能只要在500ms内触发一次，这样其实我们可以用setTimeout来解决，在这期间的触发都忽略掉。
我们可以先尝试着自己实现一个节流函数：

  // 自己实现的简单节流函数
function throttle (func, time) {
	var timeout = null,
		context = null,
		args = null
	return function() {
	    context = this
		args = arguments
		// 只要timeout函数存在，所有调用都无视
		if(timeout) return;
		timeout = setTimeout(function() {
			func.apply(context, args)
			clearTimeout(timeout)
			timeout = null
		}, time||500)
	}
}

我们实现了一个简单的节流函数，但是还不够完整，如果我想在第一次触发的时候立即执行怎么办？如果我想禁用掉最后一次执行怎么办？underscore中实现了一个比较完整的节流函数。

// options是一个对象，如果options.leading为false，就是禁用第一次触发立即调用
// 如果options.trailing为false，则是禁用第一次执行
_.throttle = function (func, wait, options) {
		// 一些初始化操作
		var context, args, result;
		var timeout = null;
		var previous = 0;
		if (!options) options = {};
		var later = function () {
			// 如果禁用第一次首先执行，返回0否则就用previous保存当前时间戳
			previous = options.leading === false ? 0 : _.now();
			// 解除引用
			timeout = null;
			result = func.apply(context, args);
			// 看到一种说法是在func函数里面重新给timeout赋值，会导致timeout依然存在，所以这里会判断!timeout
			if (!timeout) context = args = null;
		};
		return function () {
		    // 获取当前调用时的时间（ms）
			var now = _.now();
			// 如果previous为0并且禁用了第一次执行，那么将previous设置为当前时间
			// 这里用全等来避免undefined的情况
			if (!previous && options.leading === false) previous = now;
			// 还要wait时间才会触发下一次func
			var remaining = wait - (now - previous);
			context = this;
			args = arguments;
			// remaining小于0有两种情况，一种是上次调用后到现在已经到了wait时间
			// 一种情况是第一次触发的时候并且options.leading不为false，previous为0，因为now记录的是unix时间戳，所以会远远大于wait
			// remaining大于wait的情况我自己不清楚，但看到一种说法是客户端系统时间被调整过，可能会出现now小于previous的情况
			// 这两种情形下会立即执行func函数，并把previous设置为now
			if (remaining <= 0 || remaining > wait) {
				if (timeout) {
				    // 清除定时器
					clearTimeout(timeout);
					timeout = null;
				}
				// previous保存当前触发的时间戳
				previous = now;
				result = func.apply(context, args);
				if (!timeout) context = args = null;
			// 如果timeout不存在（当前定时器还存在）
			// 并且options.trailing不为false，这个时候会重新设置定时器，remaining时间后执行later函数
			} else if (!timeout && options.trailing !== false) {
				timeout = setTimeout(later, remaining);
			}
			return result;
		};
	};

这段代码看着不多，但是让我纠结了很久，运行的时候主要会有以下几种情况。

没有传leading和trailing

1. 第一次触发函数的时候，由于previous为0，而now又非常大，所以会导致remaining为负值，满足下面第一个if判断，所以会立即执行func函数（第一次触发时立即调用）并且用previous记录当前时间戳
2. 第二次触发的时候由于previous记录了前一次的时间戳，所以now - previous几乎为0，这个时候满足else if里面的判断，会设置一个定时器，这个定时器在remaining时间后执行，所以只要在remaining时间内不管我们再怎么频繁触发，由于不会满足两个if里面的条件，所以都不会执行func，一直到remaining后才会执行func
3. 之后每次触发都会重复走2的流程

options.leading: false

这种情况和上面情况类似，不过区别在于第一次触发的时候。
由于满足!previous && options.leading === false这个条件，所以previous会被设置为now，这个时候remaining等于wait，所以会走else if的分支，这样就会重复前一种情况下步骤2的流程

options.trailing: false

1. 由于没有设置leading为false，所以第一次触发就会立即执行一次func
2. 第二次触发的时候，由于previous保存了上次时间戳，所以remaining <= wait，但是又因为options.trailing为false，这样就不会走if的任何一个分支，一直到now-previous大于wait的时候（也就是过了wait时间后），这样会满足if第一个分支的条件，func会立即被执行一次
3. 之后重复步骤2

trailing和leading都为false

最好不要这么写，因为会导致一个bug的出现，如果我们在一段时间内频繁触发，这个是没什么问题，但如果我们最后一次触发后停止等待ait时间后再重新开始触发，这时候的第一次触发就会立即执行func，leading为false并没有生效。

不知道有没有人和我一样有这两个疑问，leading为false的时候，真的只是在第一次调用的时候有区别吗？trailing是怎么做到禁用最后一次执行的？
这两个问题让我昨晚睡觉前都还在纠结，还好今天在segmentfault上面有热心的用户帮我解答了。
请直接看第一个回答以及下面的评论区：关于underscore源码中throttle函数的疑惑？

leading带来的不同表现

GDUTxxZ大神给了一段代码，执行后不同的表现让我印象深刻。

var _now = new Date().getTime()
var throttle = function(func, wait, options) {
  var context, args, result;
  var timeout = null;
  var previous = 0;
  if (!options) options = {};
  var later = function() {
    previous = options.leading === false ? 0 : new Date().getTime();
    timeout = null;
    result = func.apply(context, args);
    if (!timeout) context = args = null;
  };
  return function() {
    console.log(`函数${++i}在${new Date().getTime() - _now}调用`)
    var now = new Date().getTime();
    if (!previous && options.leading === false) previous = now;
    var remaining = wait - (now - previous);
    context = this;
    args = arguments;
    // 如果超过了wait时间，那么就立即执行
    if (remaining <= 0 || remaining > wait) {
      if (timeout) {
        clearTimeout(timeout);
        timeout = null;
      }
      previous = now;
      result = func.apply(context, args);
      if (!timeout) context = args = null;
    } else if (!timeout && options.trailing !== false) {
      timeout = setTimeout(later, remaining);
    }
    return result;
  };
};
var i = 0
var test = throttle(() => {
  console.log(`函数${i}在${new Date().getTime() - _now}执行`)
}, 1000, {leading: false})

setInterval(test, 3000)

我将传入leading和没传入leading的情况作了以下比较。
leading为false时：

没有传入leading时：

当两次触发间隔时间大于wait时间的时候，很明显leading为false的时候总会在调用后延迟wait后执行func，而不传leading的时候两者是同时的，调用test的时候就直接运行了func。原本应该是callback => wait => callback

一般情况下当然不会有这种极端情况存在，但是可能出现这种情况。如果在scroll事件中，我们滚动一段距离后停止了，等wait ms后再开始滚动，这个时候如果leading为false，依然会延迟wait时间后执行，而不是立即执行，这也是为什么同时设置leading和trailing为false的时候会出现问题。

为什么是禁用最后一次调用

trailing为false时到底是怎么禁用了最后一次调用？这个也一直让我很纠结。同样的，我也写了一段代码，比较了一下两次运行后的不同结果。

var _now = new Date().getTime()
var throttle = function(func, wait, options) {
var context, args, result;
var timeout = null;
var previous = 0;
if (!options) options = {};
var later = function() {
previous = options.leading === false ? 0 : new Date().getTime();
timeout = null;
result = func.apply(context, args);
if (!timeout) context = args = null;
};
return function() {
console.log(`函数${++i}在${new Date().getTime() - _now}调用`)
var now = new Date().getTime();
if (!previous && options.leading === false) previous = now;
var remaining = wait - (now - previous);
context = this;
args = arguments;
// 如果超过了wait时间，那么就立即执行
if (remaining <= 0 || remaining > wait) {
  if (timeout) {
    clearTimeout(timeout);
    timeout = null;
  }
  previous = now;
  result = func.apply(context, args);
  if (!timeout) context = args = null;
} else if (!timeout && options.trailing !== false) {
  timeout = setTimeout(later, remaining);
}
return result;
};
};
var i = 0
var test = throttle(() => {
console.log(函数${i}在${new Date().getTime() - _now}执行)
}, 1000, {trailing: false})
window.addEventListener("scroll", test)

trailing为false时：

没有设置trailing时：

这两张图很明显的不同就是设置了trailing的时候，最后一次总是"执行"，而未设置trailing最后一次总是"调用"，少了一次执行。

我们可以假设在一种临界的场景下，比如在倒数第二次执行func后的 (wait-1) 的时间内。
如果设置了trailing，因为无法走setTimeout，所以只能等待wait时间后才能立即调用func，所以在（wait-1）的时间内无论我们触发了多少次都不会执行func函数。
如果没有设置trailing，那么肯定会走setTimeout，在这个期间触发的第一次就会设置一个定时器，等到wait时间后自动执行func函数，到（wait-1）的这段时间内不管我们触发了多少次，反正第一次触发的时候就已经设置了定时器，所以到最后一定会执行一次func函数。

总结

很久以前就使用过throttle函数，自己也实现过简单的，但是看到underscore源码后才发现原来还会有这么多令人充满想象的场景，自己所学的这点知识真的是皮毛。
我知道自己平时叙述比较罗嗦，语言又比较无聊，希望大家可以理解，如果看完还不懂，建议结合下面的参考链接。
本文有错误和不足之处，也希望大家能够指出。

参考链接：##

1. 关于underscore源码中throttle函数的疑惑？
2. underscore 函数节流的实现
3. Underscore之throttle函数源码分析以及使用注意事项
   
4. 浅谈 Underscore.js 中 _.throttle 和 _.debounce 的差异

前言

在上篇讲 Nuxt 同构问题的时候，我有提到过 NodeJS 和 webpack 的模块化实现。今天主要来讲解 webpack 中的模块化。

如果你有观察过 webpack 转换后的代码，一定会发现，不管是 import 还是 require 都会被转换成 webpack_require 这种形式。

webpack 自己实现了一套模块化的规范，使用 webpack_require 来导入模块，将其挂载到 module.exports 上面，有点儿类似 CommonJS 的模块化规范。

一个来自 QQ 群的提问

某天晚上，我的 QQ 群有个童鞋问了这么一个问题：

我也比较好奇为什么 require 引入的图片还需要在后面加个 default 呢？为什么 import 引入的却不需要？是否和 file-loader 处理图片文件有关？

带着这个疑问，于是我写了一个简单的 DEMO 来验证了一下，代码如下：

在执行了 webpack 命令后，可以看到编译后的精简代码是这样的：

webpack 模块源码分析

首先，我们可以看出来这个编译后的 js 文件就是一个立即执行函数，他接收了当前文件引入的外部模块作为一个参数，所有的外部模块被放到了一个对象当中，以当前 src 目录下的绝对路径作为 key 值，value 这是一个方法，这个方法注入了 webpack_require 和 webpack_exports 作为参数，简单来说就是类似于：

(function(modules) {
})({
 "./src/logo.png": function(module, __webpack_exports__, __webpack_require__) {
    eval("__webpack_require__.r(__webpack_exports__);\n/* harmony default export */ __webpack_exports__[\"default\"] = (__webpack_require__.p + \"a218f2cb12bf56dd2a68003790d1e986.png\");\n\n//# sourceURL=webpack:///./src/logo.png?");
  }
})

我们可以明显看到，这个图片在导出的时候，实际上是在 __webpack_exports__["default"] 里面的，那么在使用 require 引入的时候又是什么样的呢？
我们来看一下 index.tsx 被编译后的代码：

/***/ "./src/pages/home/index.jsx":
/*!**********************************!*\
  !*** ./src/pages/home/index.jsx ***!
  \**********************************/
/*! exports provided: default */
/***/ (function(module, __webpack_exports__, __webpack_require__) {

"use strict";
eval("__webpack_require__.r(__webpack_exports__);__webpack_require__.d(__webpack_exports__, \"default\", function() { return Index; }); var react__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(\"./node_modules/[email protected]@react/index.js\"); var react__WEBPACK_IMPORTED_MODULE_0___default = __webpack_require__.n(react__WEBPACK_IMPORTED_MODULE_0__); var _constants__WEBPACK_IMPORTED_MODULE_1__ = __webpack_require__(\"./src/pages/home/constants.js\");\n\n\n\nvar logo = __webpack_require__( \"./src/logo.png\");\n\nfunction Index(props) {\n  return react__WEBPACK_IMPORTED_MODULE_0___default.a.createElement(\"img\", {\n    src: logo\n  });\n}\n\n//# sourceURL=webpack:///./src/pages/home/index.jsx?");

很明显可以看到，这里在引入 logo 这个图片的时候，是直接使用 __webpack_require__ 来导入的，我们前面看到过 __webpack_require__ 的实现。

/******/ 	function __webpack_require__(moduleId) {
/******/
/******/ 		// Check if module is in cache
/******/ 		if(installedModules[moduleId]) {
/******/ 			return installedModules[moduleId].exports;
/******/ 		}
/******/ 		// Create a new module (and put it into the cache)
/******/ 		var module = installedModules[moduleId] = {
/******/ 			i: moduleId,
/******/ 			l: false,
/******/ 			exports: {},
/******/ 			hot: hotCreateModule(moduleId),
/******/ 			parents: (hotCurrentParentsTemp = hotCurrentParents, hotCurrentParents = [], hotCurrentParentsTemp),
/******/ 			children: []
/******/ 		};
/******/
/******/ 		// Execute the module function
/******/ 		modules[moduleId].call(module.exports, module, module.exports, hotCreateRequire(moduleId));
/******/
/******/ 		// Flag the module as loaded
/******/ 		module.l = true;
/******/
/******/ 		// Return the exports of the module
/******/ 		return module.exports;
/******/ 	}

这里只是返回了 module.exports，并没有 default，所以如果是直接用 require 来引入图片的话，那就肯定不会生效。
如果我们使用 import 来导入的话会怎么样呢？

/***/ "./src/pages/home/index.jsx":
/*!**********************************!*\
  !*** ./src/pages/home/index.jsx ***!
  \**********************************/
/*! exports provided: default */
/***/ (function(module, __webpack_exports__, __webpack_require__) {

"use strict";
eval("__webpack_require__.r(__webpack_exports__);__webpack_require__.d(__webpack_exports__, \"default\", function() { return Index; }); var react__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(\"./node_modules/[email protected]@react/index.js\"); var react__WEBPACK_IMPORTED_MODULE_0___default = __webpack_require__.n(react__WEBPACK_IMPORTED_MODULE_0__); var _constants__WEBPACK_IMPORTED_MODULE_1__ = __webpack_require__(\"./src/pages/home/constants.js\"); var _logo_png__WEBPACK_IMPORTED_MODULE_2__ = __webpack_require__( \"./src/logo.png\");\n\n\n\n\nvar constants = __webpack_require__( \"./src/pages/home/constants.js\");\n\nfunction Index(props) {\n  return react__WEBPACK_IMPORTED_MODULE_0___default.a.createElement(\"img\", {\n    src: _logo_png__WEBPACK_IMPORTED_MODULE_2__[\"default\"]\n  });\n}\n\n//# sourceURL=webpack:///./src/pages/home/index.jsx?");

我们明显可以看到，虽然导入的时候也没有带上一个 default，但是 React 在创建 img 标签的时候，给它带上了一个 default，关键点在于这句 return react__WEBPACK_IMPORTED_MODULE_0___default.a.createElement(\"img\", {\n src: _logo_png__WEBPACK_IMPORTED_MODULE_2__[\"default\"]\n })，所以直接用 import 也是可以导入的。

es module 和 commonjs

实际上，如果你在 NodeJS 里面使用过一些 npm 上面第三方的模块，会发现导入的时候都是要求我们使用 require('').default 的，比如大名鼎鼎的 node-xlsx：

import xlsx from 'node-xlsx';
// Or var xlsx = require('node-xlsx').default;

const data = [[1, 2, 3], [true, false, null, 'sheetjs'], ['foo', 'bar', new Date('2014-02-19T14:30Z'), '0.3'], ['baz', null, 'qux']];
var buffer = xlsx.build([{name: "mySheetName", data: data}]); // Returns a buffer

相信看了前面的分析后，你也能猜到这是为什么了吧？node-xlsx 是直接使用 export default 导出的，而 webpack 为了抹平这种差异，导致我们不得不使用 require.default 来导入它。

这是机械工业出版社的《编写可读代码的艺术》的读书笔记。

第一章：

• 好的名字、好的注释以及好的代码格式

第二章：

• 选择专业的词，比如从网上获取到数据，用fetch比用get要好得多
  
• 避免空泛的名字。
  比如在for循环里面，我们直接用i、j、k这种命名在嵌套复杂的时候并不适合，比如我们遍历一个users，我们可以用ui来代替。
• 用具体的名字代替抽象的名字。
• 为名字附带更多信息。
  比如一个变量保存了ID，但是是十六进制的，用hex_id就比id好。
  如果变量是一个度量的话，可以给名字带上单位，比如start_ms比start好。
  
• 把握住名字长度
  在小的作用域里面可以使用短的名字，但是在更大的作用域甚至全局作用域最好就别这样。
  有时候，别用首字母缩写的方式来命名变量，但是可以用eval代替evaluation，doc代替document。
• 拿掉没用的词
  比如convertToString就不如用ToString这个名字，这样没有丢失任何有用的信息。
  在html里面，可以用下划线给id命名，但是用-来分开class里面的单词

第三章：

• 用max和min表示极限，用first和last表示包含的范围
• is、has、can、should之类的词表示布尔值就更清晰

第四章：

• 使用整洁的代码格式和注释，相同的注释可以合并到一起，可以把重复的代码封装起来，这样会让代码结构变得更漂亮，代码应该根据相似性来分类，这样不会造成一大坨代码的情况。

第五章：

• 不要为了不好的变量名加注释，应该把名字改好。
• 有时候可以在注释中记录你对代码价值的见解，比如这段代码这样写可以让速度快20%。
• 为代码中的瑕疵写注释，通常写的几种标记，甚至可以把将来代码应该如何改动的想法用注释记录下来，给读者和以后的开发者提供宝贵的意见。有可能的话，可以给读者解释一下这段代码的作用
  
• 给总结性的注释，比如可以在一个负责缓存的页面最上面注释一下，这个文件是处理缓存的。可以根据情况考虑注释这段代码是"做什么的"“怎么做”“为什么”。
• 把心里想的写出来，再读一下，看看语言方面有什么可以改进的地方，并不断地改进。

第六章：

• 让注释紧凑，不要写多余的注释。
• 避免使用不明确的代词，比如你处理缓存，你用it或者this明显不容易理解，不如用cache
  

第七章：

• 写比较式的时候，一般左边是需要比较的变量，右边是常量。
• 谨慎使用三目运算符。三目运算符只在最简单的情况下使用。
• 避免使用do while循环，可以使用while来代替。
• 最小化嵌套（避免花括号嵌套很深的代码）

前言

从16年校招就开始与携程结缘，17年毕业后加入携程至今。在这短暂的一年多时间里，我受益匪浅，很感谢携程的培养，希望携程能越做越好。

初次相遇

时间回到2016年9月，我正在为校招找工作的事情急得团团转。由于对面试缺少准备，也错过了内推，又一直挂在笔试上，每天压力大到睡不着。

恰好那个时候，我收到了携程的面试电话，虽然对携程这家公司没有太多好感，但还是抱着试试的心态去参加了面试。

面试官是个温柔、和蔼的人，问了我一些问题，给我耐心地讲了这边的业务和技术栈。

后来我才知道，这位面试官是度假BU的前端老大 —— 路总。

热恋期

刚毕业的时候，我总是带着一股学生气，心理不够强大，也过于任性，总是被需求折腾的崩溃了，还好有同事包容着。

记得刚来这边的时候，我们做的还是老自由行项目，可以说是历史遗留技术债了，对于刚毕业的我来说，阅读前人代码非常吃力。原本很简单的需求，我总是要花很多天才能完成，对自己打击也比较大。

后来老大让我智伟带一下我，我还记得在这边写的第一个新页面是门票详情页。是的，那一个页面我写了整整一个多月，智伟总会指出我哪里写的不好，我也会和他讨论哪种实现更好，很感激他的耐心。

大概在工作三个月后，这边的技术栈全面更新，从原来的lizard+react换成了映杰大佬的react-imvc，这是一个集成了react、状态管理、路由和同构的框架，功能很强大，也很实用。

得益于react-imvc这个新框架，我们也随便将原来的项目迁移到新的技术栈上。DP2.0一期的时候我几乎每天都在加班，每周末都在加班，一边赶工，一边思考怎么实现功能，累并快乐着。（现在回头看，当时的代码写的不忍直视）

那时候的我，对这一切都感觉很新鲜，每天都在不断地吸收新的知识。

平淡期

转眼间，2017年就过去了，我也从一个刚毕业时懵懂的学生变成了一个稍微有些经验的社会人了。

没有了刚毕业时的繁忙，也没有了对新框架的新鲜感，我也开始把工作当做完成任务，每天都想着早点儿下班回家看看书，刷刷github，很渴望提升技术。

由于后来一直在做重复工作，我也对工作越来越没有兴趣。工作对于我来说就是打打卡而已，我也懒得关心其他的事情。这也导致了我年中的时候，就有离职跳槽的想法，但是又觉得，应该是我对工作关心太少了，只沉浸在自己的世界里面，也许应该再观察半年看看？

真正的转折点在11月份团建去三亚，每天都躺在酒店里面，无聊的时候就去游泳，简直就是神仙日子。在那段日子里，我开始思考，工作和生活的意义是什么？

我意识到自己一心沉迷于技术，却忽悠了业务的重要性。和我同时进来的小伙伴们都能独挡一面了，我却还像个襁褓中的孩子一样，需要别人把需求喂到我的嘴边，我也开始对自己的能力产生了怀疑。

至于意识怎么觉醒的呢？也许是从看到映杰开发imvc框架的时候种子就已经埋在了心里，亦或许是看到了雨飞的微信打包机器人。是啊，如果技术不能服务于产品，那又有什么用呢？

纠结良久，我胆怯地找了领导沟通，聊了聊自己这一年的状态，聊了聊自己以后想做什么，也表示自己愿意去做更多重要的、核心的业务，领导也表示赞许。

年终自评的时候，我果断地写下了，我想像映杰那样，成为一个内外兼修的技术大神，可以用自己的技术来推动业务发展。

离别

离开的想法一旦产生，就会一直埋在心底，发芽，生长。

在携程的最后两三个月，我变得更加积极、主动，也变得更乐于分享，我很清楚自己的问题在哪里，即使是亡羊补牢，我也希望能够改正自己的缺点。

领导也履行了自己的诺言，让我负责更多的业务，让我尝试去带新人。我带着新人去开会，给他们讲需求，自己也慢慢变得可以独挡一面。

可我还是会觉得无聊，没有热情。真的是我不愿意去了解业务吗？我思考了很久，我对这边的业务和产品确实不感兴趣。

重复的工作和低效率的沟通让我疲于奔命，我也知道自己是时候离开了。

终于，在年后的第一周，拒绝了领导的各种挽留后，我毅然选择提了离职。

结语

虽然很多人说，同事和朋友是两回事，可我还是要说，我在这边一年多来交到了很多不错的朋友。

我从智伟、雨飞和映杰身上学习到了很多东西，关于技术，关于业务，关于生活，这些东西也改变了我的思维方式。

最后，感谢一直和我斗嘴的智康，感谢对我很宽容照顾的卓予小姐姐，感谢能撩又调皮的秋玉小姐姐，感谢经常和我谈论人生未来的桢哥，也感谢组里面其他的小伙伴们，谢谢你们给了团队一个良好的氛围。

虽有百般不舍，但终究难免一别，希望大家以后还能再遇见。

前言

之前上家公司主要是做移动端 H5 开发的，但相关技术和配套体系已经很成熟了，很难接触到背后的这套体系。

在现在的公司也做了一些零散的 H5 页面，有一些相关实践。反而因为基础设施和体系不完善，接触到了更多东西。

刚好要搞 RN，于是恶补了一些相关的知识，顺便把 H5 开发中的一些东西也温习记录了一遍。

Native App

在说 Hybrid App 之前不得不先讲到 Native App，这是最为传统的一种移动端开发技术。

在 iOS 和安卓中官方的开发语言是 oc/swift、java/kotlin，使用这些开发出来的 App 一般称之为原生应用。

优点

原生应用一般体验较好，性能比较高，可以提前把资源下载到本地，打开速度快。

除此之外，原生应用可以直接调用系统摄像头、通讯录、相册等功能，也可以访问到本地资源，功能强大。

一般需要开发 App，原生应用应该是首选。

缺点

原生应用最大的缺点就是不支持动态化更新，这也是很多大厂不完全使用原生开发的原因。

考虑一下，如果线上出现严重问题，那该怎么办呢？

首先客户端开发修复了 bug 之后，就需要重新发版、提交应用商店审核，这一流程走下来往往需要好几天的时间。

如果发布了新版 App，用户该怎么去更新呢？答案是没法更新。他们只能重新去下载整个 App，但实际上可能只更新了一行文案，这样就得不偿失了。

除此之外，最麻烦的地方在于要兼容老版本的 App。比如我们有个列表页原本是分页加载的，接口返回分页数据。产品说这样体验不好，我们需要换成全量加载，那接口就需要做成全量的。

但接口一旦换成了全量的，老版本的客户端里面依然是分页请求接口的，这样就会出现问题。因此，接口不得不根据不同版本进行兼容。

Web App

Web App 就是借助于前端 HTML5 技术实现的在浏览器里面跑的 App，简单来说就是一个 Web 网站。

因为是在浏览器里面运行，所以天然支持跨平台，一套代码甚至很容易支持移动端和 PC 端不需要安装到手机里面，上线发版也比较容易。

缺点也很明显，那就是只能使用浏览器提供的功能，无法使用手机上的一些功能。比如摄像头、通讯录、相册等等，局限性很大。

也由于依赖于网络，加载页面速度会受到限制，体验较差。受限于浏览器 DOM 的性能，导致对一些场景很难做到原生的体验，比如长列表。
同时，也因为不像客户端一样在手机上有固定入口，会导致用户黏性比较低。

Hybrid App

Hybrid App 是介于 Native 和 Web 之间的一些开发模式，一般称作混合开发。

简单来说 Hybrid 就是套壳 App，整个 App 还是原生的，也需要下载安装到手机，但是 App 里面打开的页面既可以是 Web 的，又可以是原生的。

H5 页面会跑在 Native 的一个叫做 WebView 的容器里面，我们可以简单理解为在 App 里面打开了一个 Chrome 浏览器，在这个浏览器里面打开一个 Tab 去加载线上或者本地的 H5 页面，这样还可以实现打开多 WebView 来加载多个页面。

优势

Hybrid App 同时拥有 Native 和 Web 的优点，开发模式比较灵活。既可以做到动态化更新，有 bug 直接更新线上 H5 页面就行了。
也可以使用桥接（JS Bridge）来调用系统的摄像头、相册等功能，功能就不仅仅局限于浏览器了。

由于 H5 的优势，Hybrid 也支持跨平台，只要有 WebView，一套代码可以很容易跨iOS、安卓、Web、小程序、快应用多个平台。

缺点

缺点主要还是 Web App 的那些缺点，加载速度比较慢。

同时，因为受制于 Web 的性能，在长列表等场景依然无法做到和原生一样的体验。

当然加载速度是可以优化的，比如离线包。可以提前下载打包好的 zip 文件（包括 JS、CSS、图片等资源文件）到 App 里面，App 自己解压出来 JS 和 CSS 等文件。这样每次访问的是 App 本地的资源，加载速度可以得到质的提升。

如果文件有更新，那么客户端就去拉取远程版本，和本地版本进行对比，如果版本有更新，那就去拉取差量部分的文件，用二进制 diff 算法 patch 到原来的文件中，这样可以做到热更新。

但是成本也比较高，不仅需要在服务端进行一次文件差分，还需要公司内部提供一套热更新发布平台。

WebKit

WebView 是安卓中展示界面的一个控件，一般是用来展示 Web 界面。前面我们说过，可以把 WebView 理解为你正在使用的 Chrome 浏览器。

那么浏览器又是怎么去解析渲染 HTML 和 CSS，最终渲染到页面上面的呢？

这也是一道经典面试题里面的一环：从URL输入到页面展现到底发生什么？

简单来说就是浏览器拿到响应的 HTML 文本后会解析 HTML 成一个 DOM 树，解析 CSS 为 CSSOM 树，两者结合生成渲染树。在 Chrome 中使用 Skia 图形库来渲染界面，Skia 也是 Flutter 的渲染引擎。

可以参考这张经典图：

PS：使用 Skia 去绘制界面，而非编译成 Native 组件让系统去渲染，也是 Flutter 区别于 React Native 的一个地方。

除了解析 HTML，浏览器还需要提供 JavaScript 的运行时，我们知道的 V8 引擎就是做这件事的。

WebKit 内核

从上面我们可以得知，一个浏览器至少离不开一个渲染 HTML 的引擎和一个运行 JavaScript 的引擎。

当然，上面的这些操作都是浏览器由内核来完成的。现在主流的浏览器都使用了 WebKit 内核。

WebKit 诞生于苹果发布的 Safari 浏览器。后来谷歌基于 WebKit 创建了 Chromium 项目，在此基础上发布了我们熟悉的 Chrome 浏览器。

WebKit 内核的结构如下图所示。

我们依次从上往下看，WebKit 嵌入式接口就是提供给浏览器调用的，不同浏览器实现可能有所差异。

其中解析 HTML 和 CSS 这部分是 WebCore 做的，WebCore 是 WebKit 最核心的渲染引擎，也是各大浏览器保持一致的部分，一般包括 HTML 和 CSS 解释器、DOM、渲染树等功能。

WebKit 默认使用 JavaScriptCore 作为 JS 引擎，这部分是可以替换的。JavaScriptCore 也是 React Native 里面默认的引擎。

由于 JavaScriptCore 前期性能低下，于是谷歌在 Chrome 里面选用了 V8 作为 JS 引擎。

WebKit Ports 则是非共享的部分，由于平台差异、依赖的库不同，这部分就变成了可移植部分。主要涉及到网络、视频解码、图片解码、音频解码等功能。

WebView 自然也使用了 WebKit 内核。只是在安卓里面以 V8 作为 JS 引擎，在 iOS 里面以 JavaScriptCore 作为 JS 引擎。

由于渲染 DOM 和操作 JS 的是两个引擎，因此当我们用 JS 去操作 DOM 的时候，JS 引擎通过调用桥接方法来获取访问 DOM 的能力。这里就会涉及到两个引擎通信带来的性能损失，这也是为什么频繁操作 DOM 会导致性能低下。

React 和 Vue 这些框架都是在这一层面进行了优化，只去修改差异部分的 DOM，而非全量替换 DOM。

iOS 中的 JavaScriptCore

JavaScriptCore 是 WebKit 内核默认使用的 JS 引擎。既然是讲解 WebView，那么就来介绍一下 iOS 里面的 JavaScriptCore 框架吧。

iOS 中的 JavaScriptCore 框架是基于 OC 封装的 JavaScriptCore 框架。

它提供了调用 JS 运行环境以及 OC 和 JS 互相调用的能力，主要包含了 JSVM、JSContext、JSValue、JSExport 四个部分（其实只是想讲 JSVM）。

JSVM

JSVM 全称是 JSVirtualMachine，简单来说就是 JS 的虚拟机。那么什么是虚拟机呢？

我们以 JVM 为例，一般来说想要运行一个 Java 程序要经过这么几步：

1. 把 Java 源文件（.java文件）编译成字节码文件（.class文件，是二进制字节码文件），这种字节码就是 JVM 的“机器语言”。javac.exe 就可以看做是 Java 编译器。
2. Java 解释器用来解释执行 Java 编译器编译后的程序。java.exe可以简单看成是 Java 解释器。

所以 JVM 是一种能够运行 Java 字节码的虚拟机。除了运行 Java 字节码，它还会做内存管理、GC 等方面的事情。

而 JSVM 则提供了 JS 的运行环境，也提供了内存管理。每个 JSVM 只有一个线程，如果想执行多个线程，就要创建多个 JSVM，它们都自己独立的 GC，所以多个 JSVM 之间的对象无法传递。

JS 源代码经过了词法分析和语法分析这两个步骤，转成了字节码，这一步就是编译。

但是不同于我们编译运行 Java 代码，JS 编译结束之后，并不会生成存放在内存或者硬盘之中的目标代码或可执行文件。生成的指令字节码，会被立即被 JSVM 进行逐行解释执行。

字节码

字节码是已经经过编译，但与特定机器码无关，需要解释器转译后才能成为机器码的中间代码。

在 v8 中前期没有引入字节码，而是简单粗暴地直接把源程序编译成机器码去运行，因为他们觉得先生成字节码再去执行字节码会降低执行速度。

但后期 v8 又再一次将字节码引入进来，这是为什么呢？

早期 v8 将 JS 编译成为二进制机器码，但是编译会占用很大一部分时间。如果是同样的页面，每次打开都要重新编译一次，这样就会大大降低了效率。

于是在 chrome 中引入了二进制缓存，将二进制代码保存到内存或者硬盘里面，这样方便下次打开浏览器的时候直接使用。

但二进制代码的内存占用特别高，大概是 JS 代码的数千倍，这样就导致了如果在移动设备（手机）上使用，本来容量就不大的内存还会被进一步占用，造成性能下降。

然而字节码占用空间就比机器码实在少太多了。因此，v8 团队不得不再次引入字节码。

JIT

除此之外，还有一个大家都很熟悉的概念，那就是 JIT（即时编译）。

即时编译(Just-in-time compilation: JIT)：又叫实时编译、及时编译。是指一种在运行时期把字节码编译成原生机器码的技术，一句一句翻译源代码，但是会将翻译过的代码缓存起来以降低性能耗损。这项技术是被用来改善虚拟机的性能的。

简单来说就是某段代码要被执行之前才进行编译。还是以 JVM 为例子。

1. JVM 的解释过程：

java 代码 -> 编译字节码 -> 解释器解释执行

2. JIT 的编译过程：

java 代码 -> 编译字节码 -> 编译机器码 -> 执行

所以 Java 是一种半编译半解释语言。之所以说 JIT 快，是指执行机器码效率比解释字节码效率更高，而非编译比解释更快。因此，JIT 编译还是会比解释慢一些。

同样，编译成机器码还是会遇到上面空间占用大的问题。所以在 JIT 中只对频繁执行的代码就行编译，一般包括下面两种：

1. 被多次调用的方法。
2. 被多次执行的循环体。

在编译热点代码的时候，这部分就会被缓存起来。等下次运行的时候就不需要再次进行编译，效率会大大提升。这也是为什么很多 JVM 都是用解释器+JIT的形式。

小丁哥如是说：

JSContext

JSContext 就是 JS 运行的上下文，我们想要在 WebView 上面运行 JS 代码，就需要 JSContext 这个运行环境。以下面这段代码为例：

JSContext *context = [[JSContext alloc] init];
[context evaluateScript:@"var i = 4"];
NSNumber *number = [context[@"i"] toNumber];

上面的 JSContext 调用 evaluateScript 来执行一段 JS 代码，通过 context 可以拿到对应的 JSValue 对象。

JSValue

JS 和 OC 交换数据的时候 JSCore 帮我们做了类型转换，JSCore 提供了10种类型转换：

   Objective-C type  |   JavaScript type
 --------------------+---------------------
         nil         |     undefined
        NSNull       |        null
       NSString      |       string
       NSNumber      |   number, boolean
     NSDictionary    |   Object object
       NSArray       |    Array object
        NSDate       |     Date object
       NSBlock            |   Function object 
          id         |   Wrapper object 
        Class        | Constructor object

JSExport

JSExport 支持把 Native 对象暴露给 JS 环境。例如：

@protocol NativeObjectExport <JSExport>

@property (nonatomic, assign) BOOL property1;

- (void)method1:(JSValue *)arguments;

@end

@interface NativeObject : NSObject<NativeObjectExport>

@property (nonatomic, assign) BOOL property1;

- (void)method1:(JSValue *)arguments;


@end

上面的 NativeObject 只要实现了 JSExport，就可以被 JS 直接调用。我们需要在 Context 里面注入一个对象，就可以在 JS 环境调用 Native 了。

context[@"nativeMethods"] = [NativeObject new];

JS 中调用：

nativeMethods.method1({
    callback(data) {
    }
])

React Native

Hybrid 中的 H5 始终是 WebView 中运行的，WebKit 负责绘制的。因为浏览器渲染的性能瓶颈，Facebook 基于 React 发布了 React Native 这个框架。

由于 React 中 Virtual DOM 和平台无关的优势，理论上 Virtual DOM 可以映射到不同平台。在浏览器上就是 DOM，在 Native 里面就是一些原生的组件。

受制于浏览器渲染的性能，React Native 吸取经验将渲染这部分交给 Native 来做，大大提高了体验。个人认为 React Native 也算是 Hybrid 技术的一种。

RN 中直接使用 JavaScriptCore 来提供 JS 的运行环境，通过 Bridge 去通知 Native 绘制界面，最终还是 Native 渲染的。

所以性能上比 Hybrid 更好，但受限于 JS 和 Native 通信的性能消耗，性能上依然不及 Native。

JS 和 Native 通信原理

在 JS 和 Native 通信的时候往往要经过 Bridge，这一步是异步的。

在 App 启动的时候，Native 会创建一个 Module 配置表，这个表里面包括了所有模块和模块方法的信息。

{
    "remoteModuleConfig": {
        "XXXManager": {
            "methods": {
                "xxx": {
                    "type": "remote",
                    "methodID": 0
                }
            },
            "moduleID": 4
        },
        ...
     },
}

由于在 OC 里面每个提供给 JS 调用的模块类都实现了 RCTBridgeModule 接口，所以通过 objc_getClassList 或 objc_copyClassList 获取项目中所有的类，然后判断每个类是否实现了 RCTBridgeModule，就可以确定是否需要添加到配置表中。

然后 Native 会将这个配置表信息注入到 JS 里面，这样在 JS 里面就可以拿到 OC 里面的模块信息。

其实如果你写过 JS Bridge，会发现这个流程和 WebViewJavaScriptBridge 有些类似。主要是这么几个步骤：

1. JS 调用某个 OC 模块的方法
2. 把这个调用转换为 ModuleName、MethodName、arguments，交给 MessageQueue 处理。
3. 将 JS 的 Callback 函数放到 MessageQueue 里面，用 CallbackID 来匹配。再根据配置表将 ModuleName、MethodName映射为 ModuleID 和 MethodID。
4. 然后把上面的 ID 都传给 OC
5. OC 根据这几个 ID 去配置表中拿到对应的模块和方法
6. RCTModuleMethod 对 JS 传来的参数进行处理，主要是将 JS 数据类型转换为 OC 的数据类型
7. 调用 OC 模块方法
8. 通过 CallbackID 拿到对应的 Callback 方法执行并传参

热更新

相比 Native，RN 的一大优势就是热更新。我们将 RN 项目最后打包成一个 Bundle 文件提供给客户端加载。在 App 启动的时候去加载这个 Bundle 文件，最后由 JavaScriptCore 来执行。

如果有新版本该怎么更新？这个其实很简单，重新打包一个 Bundle 文件，用 BS Diff 算法对不同版本的文件进行二进制差分。

客户端会比较本地版本和远程版本，如果本地版本落后了，那就去下载差量文件，同样使用 BS Diff 算法 patch 进 Bundle 里面，这样就实现了热更新。

这种方式也适用于 H5 的离线包更新，可以很大程度上解决 H5 加载慢的问题。

RN 新架构

在 RN 老架构中，性能瓶颈主要体现在 JS 和 Native 通信上面，也就是 Bridge 这里。

我们写的 RN 代码会通过 JS Thread 进行序列化，然后通过 Bridge 传给 shadow Thread 反序列化获得原生布局信息。

之后又通过 Bridge 传给 UI Thread，UI Thread 反序列化之后会根据布局信息进行绘制。这里就有三个线程通过 Bridge 来通信。

由于多次序列化/反序列化以及 Bridge 通信，这样就造成了一些性能损耗。

尤其是在快速滑动列表的时候容易造成白屏，然而浏览器里面快速滑动却没有白屏，这又是为什么呢？

主要还是浏览器中，JS 可以持有 C++ 对象的引用，所以这里其实是同步调用。

由于受到 Flutter 的冲击，RN 团体提出了新的架构来解决这些问题。为了解决 Bridge 通信的问题，RN 团队在 JavaScriptCore 之上抽象了一层 JSI（JavaScript Interface），允许底层更换成不同的 JavaScript 引擎。

除此之外，JS 还可以拿到 C++ 的引用，这样就可以直接和 Native 通信，不需要反复序列化对象，也节省了 Bridge 通信的开支。

这里解释一下，为啥拿到 C++ 引用就可以和 Native 通信。由于 OC 本身就是 C 语言的扩展，所以可以直接调用 C/C++ 的方法。Java 虽然不能 C 语言扩展，但它可以通过 JNI 来调用。

JNI 就是 Java Native Interface，它是 JVM 提供的一套能够使运行在 JVM 上的 Java 代码调用 C++ 程序、以及被 C++ 程序调用的编程框架。

相信新架构的到来会解决 RN 原有的一些痛点，以及会带来性能上的飞跃。

Flutter

传统的跨端有两种，一种是 Hybrid 那种实现 JS 跑在 WebView 上面的，这种性能瓶颈取决于浏览器渲染。

另一种是将 JS 组件映射为 Native 组件的，例如 React Native、Weex，缺点就是依然需要 JS Bridge 来进行通信（老架构）。

Flutter 则是在吸取了 RN 的教训之后，不再去做 Native 的映射，而是自己用 Skia 渲染引擎来绘制页面，而 Skia 就是前面说过的 Chrome 底层的二维图形库，它是 C/C++ 实现的，调用 CPU 或者 GPU 来完成绘制。所以说 Flutter 像个游戏引擎。

Flutter 在语法上深受 React 的影响，使用 setState 来更新界面，使用类似 Redux 的**来管理状态。从早期的 WPF，到后面的 React，再到后来的 SwiftUI 都使用了声明式 UI 的**。

Flutter 架构图如下：

Framework 是用 Dart 实现的 SDK，封装了一些基础库，比如动画、手势等。还实现了一套 UI 组件库，有 Material 和 Cupertino 两种风格。Material 适用于安卓，Cupertino 适用于 iOS。

Engine 是 C/C++ 实现的 SDK，主要包括了 Skia 引擎、Dart 运行时、文本渲染等。

Embedder 是一个嵌入层，支持把 Flutter 嵌入各个平台。

Flutter 使用 Dart，支持 AOT 编译成 ARM Code，这样拥有更高的性能。在 Debug 模式下还支持 JIT。

在 Flutter 中，Widgets 是界面的基本构成单位，和 React Component 有些类似。而 StatelessWidget 类似 React Functional Component。

class Echo extends StatelessWidget {
  const Echo({
    Key key,  
    @required this.text,
    this.backgroundColor:Colors.grey,
  }):super(key:key);

  final String text;
  final Color backgroundColor;

  @override
  Widget build(BuildContext context) {
    return Center(
      child: Container(
        color: backgroundColor,
        child: Text(text),
      ),
    );
  }
}

在 Flutter 渲染过程中有三棵树，分别是 Widgets 树、Element 树、RenderObject 树。

如果你有写过 React，会发现真的和 React 很类似。

当初始化的时候， Widgets 通过 build 方法来生成 Element，这类似于 React.createElement 生成虚拟 DOM（Virtual DOM）。

Element 重新创建的开销会比较大，所以每次重新渲染它并不会重新构建。从 Element Tree 到 RenderObject Tree 之间一般也会有一个 Diff 的环境，计算最小需要重绘的区域。

这里也和 React 渲染流程比较相似，虚拟 DOM 会和真实 DOM 进行一次 Diff 对比，最后将差异部分渲染到浏览器上。

浏览器渲染

在前面我们讲过浏览器的渲染流程。一般是将 HTML 解析成 DOM 树，将 CSS 解析为 CSSOM 树，两者合并成一颗 RenderObject 树。

一个 RenderObject 对象保存了绘制 DOM 节点需要的各种信息，它知道怎么绘制自己。不同的 RenderObject 对象构成一棵树，就叫做 RenderObject 树。它是基于 DOM 树创建的一棵树。

然后 WebKit 会为这些 RenderObject 对象创建新的 RenderLayer 对象，最后形成一棵 RenderLayer 树。一般来说，RenderLayer 和 RenderObject 是一对多的关系。每个 RenderLayer 包括的是 RenderObect 树的子树。

什么情况下会创建 RenderLayer 对象呢？比如 Video 节点、Document 节点、透明的 RenderObject 节点、指定了位置的节点等等，这些都会创建一个 RenderLayer 对象。

一个 RenderLayer 可以看做 PS 里面的一个图层，各个图层组成了一个图像。

Flutter 渲染

Flutter 渲染和浏览器渲染类似，Widget 通过 createElement 生成 Element，而 Element 通过 createRenderObject 创建了 RenderObject 对象，最终生成 Layer。

一般来说，RenderObject 上面存着布局信息，所以布局和绘制都是在 RenderObject 中完成。Flutter 通过深度遍历渲染 RenderObject 树，确定每个对象的位置和大小，绘制到不同的图层中。绘制结束后，由 Skia 来完成合成和渲染。

所以 Flutter 的更新流程如下：

通信

Flutter 没办法完成 Native 所有的功能，比如调用摄像头等，所以需要我们开发插件，而插件开发的基础还是 Flutter 和 Native 之间进行通信。

Flutter 和 Native 之间的通信是通过 Channel 完成的，一般有下面几种通信场景：

1. Native 发送数据给 Dart
2. Dart 发送数据给 Native
3. Dart 发送数据给 Native，Native 回传数据给 Dart

Flutter 实现通信有下面三种方式：

1. EventChannel：一种 Native 向 Flutter 发送数据的单向通信方式，Flutter 无法返回任何数据给 Native。一般用于 Native 向 Flutter发送手机电量、网络连接等。
2. MethodChannel：Native 和 Flutter之间的双向通信方式。通过 MethodChannel 调用 Native 和 Flutter 中相对应的方法，该种方式有返回值。
3. BasicMessageChannel：Native 和 Flutter之间的双向通信方式。支持数据类型最多，使用范围最广。该方式有返回值。

BinaryMessenger 是 Flutter 和 Channel 通信的工具。它在安卓中是一个接口，使用二进制格式数据通信。

在 FlutterView 中实现，它可以通过 JNI 来和系统底层通信。因此，基本上和原生调用差不多，不像 RN 中 Bridge 调用需要进行数据转化。

所以，如果想开发插件，还是需要实现安卓和 iOS 的功能，以及封装 plugin 的 api，总体上还是无法脱离 Native 来运作。

对比 React Native

1. Flutter 官方暂时不支持热更新，RN 有成熟的 Code Push 方案
2. Flutter 放弃了 Web 生态，RN 拥有 Web 成熟的生态体系，工具链更加强大。
3. Flutter 将 Dart 代码 AOT 编译为本地代码，通信接近原生。RN 不仅需要多次序列化，不同线程之间还需要通过 Bridge 来通信，效率低下。

更多细节对比可以参考知乎这个问题：开发跨平台 App 推荐 React Native 还是 Flutter？

参考

1. Understanding WebViews
   
2. What is WebKit and how is it related to CSS?
   
3. 在Chrome中的GPU加速合成(一)
4. JavaScriptCore
5. JIT 为什么能大幅度提升性能？
   
6. 深入浅出 JIT 编译器
   
7. How Flutter renders Widgets
8. Flutter原理及经验分享
   
9. WebKit 技术内幕
10. React Native's New Architecture

前几天在知乎看到了这个问题，刚好前阵子做过，就回答了一下。下面的是原回答。

前言

前阵子有搞了 React 服务端渲染的项目，是否应该用这个主要还是看场景吧。

比较适用于大家常说的 SEO 和首屏渲染这些，一般都是 toc 的业务才会需要用到。

同构

现代框架的服务端渲染和 jsp、php 这些还是有不少区别的。因为 nextjs 和 nuxtjs 这种不仅仅是服务端渲染，它们还是同构框架。

什么是同构呢？就是一份代码既可以跑在浏览器端，也可以跑在服务端。这得益于 NodeJS 在服务端的流行。

传统 jsp、php、django 这些服务端渲染框架都是返回 html 字符串，类似于传统的 MPA 多页面模式。所以切换页面的时候就会刷新，重新请求 css 和 js 文件，用户体验比较差。

而现在流行的前端开发模式都是 SPA 单页面，基于 H5 的 History 来实现切换页面无刷新，这样可以带来更好的用户体验。

所以 nextjs 和 nuxtjs 不仅支持服务端渲染，还支持 SPA，常用的是对首页进行服务端渲染，其他页面依然保持 SPA 的无刷新访问模式。

我们这边就有使用 Django 来编写的页面，维护起来很痛苦。因为无法说清楚哪些是前端负责的，哪些是后端负责的。所以为了维护这个，前端和后端都去要学习 Python 和 Django，大大提高了维护成本。

实际应用场景的话，我们这里有几种场景就比较适合用服务端渲染。

支持 Post 请求

一个是重构的 h5 页面，项目以前是新加坡团队用 Python + Django 写的，所以有些页面是第三方网站 Post 提交表单打开的。

我们重构后的 H5 页面都挂在腾讯云 CDN 上面，不支持用 Post 打开的。为什么不改成 Get 呢？因为这是以前他们协定的，然后银行都是爸爸，他们不会为了我们去改协议的。

页面功能都是比较简单的，所以为了赶上重构的时间线，当时旁边的小伙伴用 Express + EJS 实现了一版，只支持 ES5 的语法。

后续需求经历几次变更，想在原来的页面上加功能都比较麻烦。比如我想实现 JS Bridge，我只能用 microbundle 把现有的 npm 包打成一个 umd 文件，然后用 script 标签引入。

动态渲染标题

前阵子遇到了另一个需求，我需要为多家银行实现同样的 H5 页面，功能基本上都是一样的，但 App 头部需要展示不同银行的名字。

在我们 AirPay App 里面，客户端在打开 webview 的时候会去读取我们 HTML 里面的 title，将其设置为原生头部的标题。

如果我在代码里面使用 document.title 的方式动态设置就不会生效，只能通过 JS Bridge 来动态设置头部。

但这个页面不仅会提供给 AirPay 使用，还会提供給 Shopee 使用，需要兼容两套 JS Bridge，有点儿得不偿失。

但如果使用服务端直出的形式，就可以在服务端直接判断好需要渲染的标题，设置到 HTML 的 title 里面。这就是另一种适合的业务场景了。

所以在之前项目基础上添加了 React 服务端渲染的功能，支持用 React 开发同构应用。这里也没有用 Next，只是自己实现的一套同构。

大致实现思路是用 isomorphic-style-loader 和 universal-router 来处理样式和路由的同构，服务端获取到数据后输出到 window._INITIAL_STATE__ 里面，在浏览器获取这个初始化数据实现数据同构的。

同时也保留了原来的 EJS 模板，都是基于 Express 路由分发的，既可以渲染用 EJS 渲染，也可以用 React 服务端直出。

一期的这个页面是挂在腾讯云 CDN 上面的，二期使用了服务端渲染，可以明显感觉到加载速度变快了很多，毕竟以前还是会展示一个 loading 图。

在进程守护方面，整个部门的 Node 服务都是用大佬写的 Node Agent 来做，也经受住了各种大促的考验。

性能测试

这次测试是用 h5-pay 和 h5-ssr 里面的 mbanking 做的一个对比，打开浏览器隐身模式，disable cache 之后，测试了弱网和正常网速下的比较。

h5-ssr 是我们这边用于服务端渲染的项目，静态资源挂载到了腾讯云的 CDN 上面。h5-pay 是我们这边的一个静态项目，html 和静态资源都挂载到了 CDN 上面。

指标

页面加载速度上面的差距是显而易见的。这里使用了浏览器自带的 Performance API 来做一个对比，具体就是加载完页面后执行 performance.getEntites() 来查看各项指标。

这次主要对比的是 DNS 解析、TCP 连接、请求响应、DOM 解析等等。

DNS 解析

首先我们可以看到 DNS 解析时间，一般是 domainLookupEnd - domainLookupStart，很显然 h5pay 的解析速度很慢，达到了惊人的 94ms，这个域名是我们关联在腾讯云上面的。

反而 SSR 的 DNS 解析只花了 3ms，这里是否可以说明我们自己解析速度远远快过腾讯云的解析速度呢？

TCP 连接

TCP 连接这个两者差距不大，一般是 connectEnd - conntectStart 来查看，SSR 耗时大概 40ms，h5pay 耗时 60ms。

首次请求响应

对比完 DNS 之后，我们再来对比一下首次请求的响应耗时。这个首次请求是指我们在浏览器输入 URL 之后，等浏览器三次握手建立 TCP 连接之后，请求获取我们的 HTML 文件的耗时。

这里使用 responseEnd - requestStart 来比较耗时。需要注意的是，走 SSR 的页面一般都需要在服务端请求接口，获取数据后将数据一起返回给浏览器，所以理论上 SSR 耗时肯定比非 SSR 更多。

这里可以看到差距非常大，h5-ssr 只花了 102 ms，但 h5-pay 耗时居然到了 390ms，不是说好的 SSR 耗时会更多吗！

那么只有一种解释，就是腾讯云 CDN 实在过于垃跨了，请求响应速度实在是太慢了，以至于別人顺便请求了一个接口都只花了100ms，你反而花了快400ms。

DOM 解析

因为 SSR 是已经在服务端渲染好了数据，所以它返回的 DOM 就是全量的。但 h5-pay 不一样，它是单页应用，大部分逻辑都在 JS 里面，反而 HTML 本身很小，只是个空壳。所以这里必然是 h5-pay 解析比 SSR 更快。

我们用 domInteractive - responseEnd 来比较一下，发现 SSR 解析 DOM 耗时达到了 800ms，而 h5-pay 耗时只有 340ms，这是 h5-pay 的一次重大胜利。

整体耗时

最上面的 duration 可以看到整体耗时，SSR 耗时在 1000ms 左右，而 h5-pay 耗时在 5817 ms，当然这个数据不是非常准确的，因为 5817ms 算上了加载完所有的静态资源，而 SSR 只要 DOM 解析完就算加载完成了。

如果是从 DNS 解析到 DOM 渲染耗时来看，h5-pay 更胜一筹，但这个并没有什么用。因为 SSR 这个耗时就已经把整个页面直出了，而 h5-pay 还需要去下载 JS 文件，然后调接口获取数据，再进行一次重绘。

如果只算 H5-PAY 的关键资源加载以及调接口、重绘的耗时，大概在 3s 左右，而走了 SSR 的相同页面仅仅花了 1s，性能差距大概 2倍。

缺点

当然了，服务端渲染也不应该滥用。

比如我们的内部后台管理系统就上了 Nuxt，现在每次本地构建要花10分钟，非常影响开发效率。

Nuxt 功能还是非常强大的，比如会根据路由动态拆分构建文件、鼠标放到 Nuxt-link 路由组件上面就会预加载 JS 文件等等。

但实际上带来的收益几乎为零，因为我们不需要 SEO，也不需要提高首屏加载速度。

几乎组里面每个人都有尝试用各种手段去优化构建，但效果不是很明显。直到最近开始做微前端拆分，才曲线解决这个问题。

除此之外，服务端渲染在写法上也和客户端渲染有一些区别，容易导致 bug。

比如下面在 Vuex 的 state 文件里面的这段代码：

const date = moment().format('YYYY-MM-DD')

export default () => ({
  date
})

打开页面的时候，时间应该展示的是今天。哪怕页面放置刚好跨天了，打开再刷新也应该是当天时间。

但在 Nuxt 里面，这个展示的日期就是你服务启动那天的日期，不管你怎么刷新，它永远不会变化。

因为 Nuxt 初始化的时候会把这些数据存到 store 里面，后续再怎么刷新，这个文件也不会在服务端重新加载，因为模块会被 Node 缓存起来，所以日期就不会更新。

但在客户端渲染里面，由于页面刷新会导致浏览器端重新加载 JS 文件，这个日期也会重新计算。

本文是underscore源码剖析系列第六篇文章，上节我们介绍了throttle节流函数的实现，这节将会介绍一下节流函数的兄弟 —— debounce防抖动函数。
throttle函数是在高频率触发的情况下，为了防止函数的频繁调用，将其限制在一段时间内只会调用一次。而debounce函数则是在频繁触发的情况下，只在触发的最后一次调用一次，想像一下如果我们用手按住一个弹簧，那么只有等到我们把手松开，弹簧才会弹起来，下面我用一个电梯的例子来介绍debounce函数。

电梯

假如我下班的时候去坐电梯，等了一段时间后，电梯正准备关上门下降，这个时候一个同事走了过来，电梯门被打开，这样电梯就会继续等一段时间，如果中间一直有人进来，那么电梯就一直不会下降，直到最后一个人进来后过了一定时间后还没有下一个人进来，这时电梯才会下降。

应用场景

除了电梯，事实上我们还有很多应用场景，比如我用键盘不断输入文字，我希望等最后一次输入结束后才会调用接口来请求展示联想词，如果每次输入一个字的时候就会调用接口，这样调用未免太过于频繁了。

未使用debounce的输入：

使用debounce的输入：

简单的debounce

知道debounce的工作原理了，我们可以先自己实现一个比较简单的debounce函数。

function debounce(func, wait) {
	var timeout,
		args, 
		context
	var later = function() {
		func.apply(context, args)
		timeout = context = args = null
	}
	return function() {
		context = this
		args = arguments
		// 每次触发都清理掉前一次的定时器
		clearTimeout(timeout)
		// 只有最后一次触发后才会调用later
		timeout = setTimeout(later, wait)
	}
}

麻雀虽小，五脏俱全。
不过这个函数还是有很多问题，比如每次触发都要反复的清除和设置定时器，我们来看一下underscore的实现。

underscore debounce

// debounce函数传入三个参数，分别是要执行的函数func，延迟时间wait，是否立即执行immediate
// 如果immediate为true，那么就会在wait时间段一开始就执行一次func，之后不管触发多少次都不会再执行func
// 在类似不小心点了提交按钮两下而提交了两次的情况下很有用
_.debounce = function (func, wait, immediate) {
		var timeout, args, context, timestamp, result;

		var later = function () {
		    // 这个是最关键的一步，因为每次触发的时候都要记录当前timestamp
		    // 但是later是第一次触发后wait时间后执行的，_now()减去第一次触发时的时间当然是等于wait的
		    // 但是如果后续继续触发，那么_.now() - timestamp肯定会小于wait
		    // last是执行later的时间和上一次触发的时间差
			var last = _.now() - timestamp;
            // 如果在later执行前还有其他触发，那么就会重新设置定时器
            // last >= 0应该是防止客户端系统时间被调整
			if (last < wait && last >= 0) {
				timeout = setTimeout(later, wait - last);
			// 如果last大于等于wait，也就是说设置timeout定时器后没有再触发过
			} else {
				timeout = null;
				// 这个时候如果immediate不为true，就会立即执行func函数，这也是为什么immediate为true的时候只会执行第一次触发
				if (!immediate) {
					result = func.apply(context, args);
					// 解除引用
					if (!timeout) context = args = null;
				}
			}
		};

		return function () {
			context = this;
			args = arguments;
			// 每次触发都用timestamp记录时间戳
			timestamp = _.now();
			// 第一次进来的时候，如果immediate为true，那么会立即执行func
			var callNow = immediate && !timeout;
			// 第一次进来的时候会设置一个定时器
			if (!timeout) timeout = setTimeout(later, wait);
			if (callNow) {
				result = func.apply(context, args);
				context = args = null;
			}

			return result;
		};
	};

underscore的实现比较巧妙，为了防止出现我们上面那种不停地清除、设置定时器的情况，underscore则会在每次触发时都记录时间戳，在wait时间后定时器触发执行later函数时计算当前时间和时间戳之差，如果小于wait时间，那么在之后肯定还有其他触发，这时再重新设置定时器，这样不仅解决了上面的问题，也保证了最后一次触发后wait时间才会执行func。

同时，在我们的基础之上，underscore加入了immediate参数。如果传入的immediate为true，那么只会在第一次进来的时候立即执行。很明显在上面代码中func执行只有两处，一个是callNow判断里面，一个是!immediate判断里面，所以这样保证了后续触发不会再执行func。

参考链接：
1、浅谈throttle以及debounce的原理和实现

前言

前端组件化一直是老生常谈的话题，在前面介绍 React 的时候我们已经提到过 React 的一些优势，今天则是带大家了解一下组件设计原则。

jQuery 插件

在开始讲 React 组件之前，我们还是要先来聊聊 jQuery。在我看来，jQuery 插件就已经具备了组件化的雏形。

在 jQuery 还大行其道的时代，我们在网上可以到处一些 jQuery 插件，里面有各种丰富的插件，比如轮播图、表单、选项卡等等。

组件？插件？

组件和插件的区别是什么呢？插件是集成到某个平台上的，比如 Jenkins 插件、Chrome 插件等等，jQuery 插件也类似。平台只提供基础能力，插件则提供一些定制化的能力。
而组件则是偏向于 ui 层面的，将 ui 和业务逻辑封装起来，供其他人使用。

封装 DOM 结构

在一些最简单无脑的 jQuery 插件中，它们一般会将 DOM 结构直接写死到插件中，这样的插件拿来即用，但限制也比较大，我们无法修改插件的 DOM 结构。

// 轮播图插件
$("#slider").slider({
    config: {
        showDot: true, // 是否展示小圆点
        showArrow: true // 是否展示左右小箭头
    }, // 一些配置
    data: [] // 数据
})

还有另一种极端的插件，它们完全不把 DOM 放到插件中，但会要求使用者按照某种固定格式的结构来组织代码。
一旦结构不准确，就可能会造成插件内部获取 DOM 出错。但这种插件的好处在于可以由使用者自定义具体的 DOM 结构和样式。

<div id="slider">
    <ul class="list">
        <li data-index="0"><img src="" /></li>
        <li data-index="1"><img src="" /></li>
        <li data-index="2"><img src="" /></li>
    </ul>
    <a href="javascript:;" class="left-arrow"><</a>
    <a href="javascript:;" class="left-arrow">></a>
    <div class="dot">
        <span data-index="0"></span>
        <span data-index="1"></span>
        <span data-index="2"></span>
    </div>
</div>

$("#slider").slider({
    config: {} // 配置
})

当然，你也可以选择将 DOM 通过配置传给插件，插件内部去做这些渲染的工作，这样的插件比较灵活。有没有发现？这和 render props 模式非常相似。

$("#slider").slider({
    config: {}, // 配置
    components: {
        dot: (item, index) => `<span data-index=${index}></span>`,
        item: (item, index) => `<li data-index=${index}><img src=${item.src} /></li>`
    }
})

React 组件设计

前面讲了几种 jQuery 插件的设计模式，其实万变不离其宗，不管是 jQuery 还是 React，组件设计**都是一样的。

个人觉得，组件设计应该遵循以下几个原则：

1. 适当的组件粒度：一个组件尽量只做一件事。
2. 复用相同部分：尽量复用不同组件相同的部分。
3. 松耦合：组件不应当依赖另一个组件。
4. 数据解耦：组件不应该依赖特定结构的数据。
5. 结构自由：组件不应该封闭固定的结构。

容器组件与展示组件

顾名思义，容器组件就是类似于“容器”的组件，它可以拥有状态，会做一些网络请求之类的副作用处理，一般是一个业务模块的入口，比如某个路由指向的组件。我们最常见的就是 Redux 中被 connect 包裹的组件。
容器组件有这么几个特点：

1. 容器组件常常是和业务相关的。
2. 统一的数据管理，可以作为数据源给子组件提供数据。
3. 统一的通信管理，实现子组件之间的通信。

展示组件就比较简单的多，在 React 中组件的设计理念是 view = f(data)，展示组件只接收外部传来的 props，一般内部没有状态，只有一个渲染的作用。

适当的组件粒度

在项目开发中，可能你会看到懒同事一个几千行的文件，却只有一个组件，render 函数里面又臭又长，让人实在没有读下去的欲望。
在写 React 组件中，我见过最恐怖的代码是这样的：

function App() {
    let renderHeader,
        renderBody,
        renderHTML
    if (xxxxx) {
        renderHeader = <h1>xxxxx</h1>
    } else {
        renderHeader = <header>xxxxx</header>
    }
    if (yyyyy) {
        renderBody = (
            <div className="main">
                yyyyy
            </div>
        )
    } else {
        ...
    }
    if (...) {
        renderHTML = ...
    } else {
        ...
    }
    return renderHTML
}

当我看到这个组件的时候，我想要搞清楚他最终都渲染了什么。看到 return 的时候发现只返回了 renderHTML，而这个 renderHTML 却是经过一系列的判断得来的，相信没人愿意去读这样的代码。

拆分 render

我们可以将 render 方法进行一系列的拆分，创建一系列的子 render 方法，将原来大的 render 进行分割。

class App extends Component {
	renderHeader() {}
	renderBody() {}
	render() {
		return (
			<>
				{this.renderHeader()}
				{this.renderBody()}
			</>
		)
	}
}

当然最好的方式还是拆分为更细粒度的组件，这样不仅方便测试，也可以配合 memo/PureComponent/shouldComponentUpdate 做进一步性能优化。

const Header = () => {}
const Body = () => {}
const App = () => (
	<>
		<Header />
		<Body />
	</>
)

复用相同部分

对于可复用的组件部分，我们要尽量做到复用。这部分可以是状态逻辑，也可以是 HTML 结构。
以下面这个组件为例，这样写看上去的确没有大问题。

class App extends Component {
    state = {
        on: props.initial
    }
    toggle = () => {
        this.setState({
            on: !this.state.on
        })
    }
    render() {
        <>
            <Button type="primary" onClick={this.toggle}> {this.on ? "Close" : "Open"} Modal </Button>
            <Modal visible={this.state.on} onOk={this.toggle} onCancel={this.toggle}/>
        </>
    }
}

但如果我们有个 checkbox 的按钮，它也会有开关两种状态，完全可以复用上面的 this.state.on 和 this.toggle，那该怎么办呢？

就像上一节讲的一样，我们可以利用 render props 来实现状态逻辑复用。

// 状态提取到 Toggle 组件里面
class Toggle extends Component {
    constructor(props) {
        this.state = {
            on: props.initial
        }
    }
    toggle = () => {
        this.setState({
            on: !this.state.on
        })
    }
    render() {
        return this.props.children({
            on: this.state.on,
            toggle: this.toggle
        })
    }
}
// Toggle 结合 Modal
function App() {
    return (
        <Toggle initial={false}>
            {({ on, toggle }) => (
                <>
                    <Button type="primary" onClick={toggle}> Open Modal </Button>
                    <Modal visible={on} onOk={toggle} onCancel={toggle}/>
                </>
            )}
        </Toggle>
    )
}
// Toggle 结合 CheckBox
function App() {
    return (
        <Toggle initial={false}>
            {({ on, toggle }) => (
                <CheckBox visible={on} toggle={toggle} />
            )}
        </Toggle>
    )
}

或者我们可以用上节讲过的 React Hooks 来抽离这个通用状态和方法。

const useToggle = (initialState) => {
    const [state, setState] = useState(initialState);
    const toggle = () => setState(!state);
    return [state, toggle]
}

除了这种状态逻辑复用外，还有一种 HTML 结构复用。比如有两个页面，他们都有头部、轮播图、底部按钮，大体上的样式和布局也一致。如果我们对每个页面都写一遍，难免会有一些重复，像这种情况我们就可以利用高阶组件来复用相同部分的 HTML 结构。

const PageLayoutHoC = (WrappedComponent) => {
    return class extends Component {
        render() {
            const {
                title,
                sliderData,
                onSubmit,
                submitText
                ...props
            } = this.props
            return (
                <div className="main">
                    <Header title={title} />
                    <Slider dataList={sliderData} />
                    <WrappedComponent {...props} />
                    <Button onClick={onSubmit}>{submitText}</Button>
                </div>
            )
        }
    }
}

组件松耦合

松耦合一般是和紧耦合相对立的，两者的区别在于：

1. 多个组件之间互相了解、依赖彼此的实现和方法，破坏组件的独立性，这种叫做紧耦合。

2. 多个组件之间很少、甚至没有依赖彼此的实现，一个组件的改动不会影响到其他组件，这种叫做松耦合。

   很明显，我们在开发中应当使用松耦合的方式来设计组件，这样不仅提供了复用性，还方便了测试。

   我们来看一下简单的紧耦合反面例子：

   class App extends Component {  
     state = { count: 0 }
   	increment = () => {
   		this.setState({
   			count: this.state.count + 1
   		})
   	}
   	decrement = () => {
   		this.setState({
   			count: this.state.count - 1
   		})
   	}
     render() {
       return <Counter count={this.state.count} parent={this} />
     }
   }
   
   class Counter extends Component {
     render() {
       return (
         <div className="counter">
           <button onClick={this.props.parent.increment}>
             Increase
           </button> 
           <div className="count">{this.props.count}</div>
           <button onClick={this.props.parent.decrement}>
             Decrease
           </button>
         </div>
       )
     }
   }
   

   可以看到上面的 Counter 依赖了父组件的两个方法，一旦父组件的 increment 和 decrement 改了名字呢？那 Counter 组件只能跟着来修改，破坏了 Counter 的独立性，也不好拿去复用。

   所以正确的方式就是，组件之间的耦合数据我们应该通过 props 来传递，而非传递一个父组件的引用过来。

   class App extends Component {  
     state = { count: 0 }
   	increment = () => {
   		this.setState({
   			count: this.state.count + 1
   		})
   	}
   	decrement = () => {
   		this.setState({
   			count: this.state.count - 1
   		})
   	}
     render() {
       return <Counter count={this.state.count} increment={this.increment} decrement={this.decrement}/>
     }
   }
   
   class Counter extends Component {
     render() {
       return (
         <div className="counter">
           <button onClick={this.props.increment}>
             Increase
           </button> 
           <div className="count">{this.props.count}</div>
           <button onClick={this.props.decrement}>
             Decrease
           </button>
         </div>
       )
     }
   }
   

数据解耦

我们的组件不应该依赖于特定格式的数据，组件中避免出现 data.xxx 这种数据。你可以通过 render props 的模式将要处理的对象传到外面，让使用者自行操作。
举个栗子：
我设计了一个 Tabs 组件，我需要别人给我传入这样的结构：

[
    {
        key: 'Tab1',
        content: '这是 Tab 1',
        title: 'Tab1'
    },
    {},
    {}
]

这个 key 是我们用来关联所有 Tab 和当前选中的 Tab 关系的。比如我选中了 Tab1，当前的 Tab1 会有高亮显示，就通过 key 来关联。
而我们的组件可能会这样设计：

<Tabs data={data} currentTab={'Tab1'} />

这样的设计不够灵活，一个是耦合了数据的结构，大多数时候，接口不会返回上图中的 key 这种字段，title 也很可能没有，这就需要我们自己做一下数据格式化。
另一个是封装了 DOM 结构，如果我们想定制化传入的 Tab 结构就会变得非常困难。
我们不妨转换一下思路，当设计一个通用组件的时候，一定要只有一个组件吗？一定要把数据传给组件吗？
那么来一起看看业界知名的组件库 Ant Design 是如何设计 Tabs 组件的。

<Tabs defaultActiveKey="1" onChange={callback}>
    <TabPane tab="Tab 1" key="1">
        Content of Tab Pane 1
    </TabPane>
    <TabPane tab="Tab 2" key="2">
        Content of Tab Pane 2
    </TabPane>
    <TabPane tab="Tab 3" key="3">
        Content of Tab Pane 3
    </TabPane>
</Tabs>

Ant Design 将数据和结构进行了解耦，我们不再传列表数据给 Tabs 组件，而是自行在外部渲染了所有的 TabPane，再将其作为 Children 传给 Tabs，这样的好处就是组件的结构更加灵活，TabPane 里面随便传什么结构都可以。

结构自由

一个好的组件，结构应当是灵活自由的，不应该对其内部结构做过度封装。我们上面讲的 Tabs 组件其实就是结构自由的一种代表。

考虑到这样一种业务场景，我们页面上有多个输入框，但这些输入框前面的 Icon 都是不一样的，代表着不同的含义。我相信肯定不会有人会对每个 Icon 都实现一个 Input 组件。

你可能会想到我们可以把图片的地址当做 props 传给组件，这样不就行了吗？但万一前面不是 Icon 呢？而是一个文字、一个符号呢？

那我们是不是可以把元素当做 props 传给组件呢？组件来负责渲染，但渲染后长什么样还是使用者来控制的。这就是 Ant Design 的实现思路。

在前面数据解耦中我们就讲过了类似的思路，实际上数据解耦和结构自由是相辅相成的。在设计一个组件的时候，很多人往往会陷入一种怪圈，那就是我该怎么才能封装更多功能？怎么才能兼容不同的渲染？

这时候我们就不妨换一种思路，如果将渲染交给使用者来控制呢？渲染成什么样都由用户来决定，这样的组件结构是非常灵活自由的。

当然，如果你把什么都交给用户来渲染，这个组件的使用复杂度就大大提高了，所以我们也应当提供一些默认的渲染，即使用户什么都不传也可以渲染默认的结构。

总结

组件设计是一项重要的工作，好的组件我们直接拿来复用可以大大提高效率，不好的组件只会增加我们的复杂度。

在组件设计的学习中，你需要多探索、实践，多去参考社区知名的组件库，比如 Ant Design、Element UI、iview 等等，去思考他们为什么会这样设计，有没有更好的设计？如果是自己来设计会怎么样？

2020-11-23

monorepo、yarn workspace、lerna

问题描述

ATM BillPayment 上线后，local 在 live 环境发现输入框的日期默认是 07-22 的，于是报了问题。

我看了一下代码，进来页面的时候，我默认设置的是当天的日期，不可能是 07-22 的。在本地跑一下发现是正常的，但是打开 live 后不管怎么刷新页面，日期就是停留在 07.22 这天。

问题定位

于是，我先怀疑这里是否有问题。问了一下 QA，上次发布 live 的日期是不是 07.22，他说是的。

我打开 UAT 环境的看了一下，发现停留在了 07.23，也刚好是那天发布了 UAT。

看起来时间都停留在了发布的那天。

第一步，肯定是先翻自己的代码。这段逻辑是放到 vuex 的 state 里面的。

虽然是个闭包，但正常情况下，我们刷新浏览器也会重新计算 date。可是这里没有重新计算。

问题思考

为什么页面上的日期会停留在发布服务的那天呢？

页面上的日期和服务有什么关系呢？

…...

是不是服务端渲染的问题呢？

这就不得不讲一下模块和同构了。

闭包 & 模块

当我们在不同模块中引入同一个模块 m，那么这个 m 被执行了几次呢？

一次？还是引入几次就执行几次？

答案是一次。为什么只执行了一次呢？

如果你用立即执行函数做过简单的模块，那么下面这段代码就豁然开朗。

在 webpack 中，加载模块也是进行了缓存，可以查看 webpack 将文件编译之后，他们是如何实现 require 的。

很显然，在 webpack 中对第一次引入的模块进行了缓存，后续读取都是从缓存中来的。webpack 中解析模块代码使用的还是 eval。

而在 Node 中，CommonJS 的原理也是类似，只是解析代码这块儿是用 C++ 来实现的。这里是源码地址：https://github.com/nodejs/node/blob/a6a3684984/lib/internal/modules/cjs/loader.js

这说明了什么呢？我们的 state 模块，不管是被引入多少次，那么都只会被加载一次。

同构

在 Nuxt 中，服务端渲染是通过 vue-server-renderer 的 renderToString 方法来实现的。

一般情况下，SPA 应用对 SEO 不友好，首页加载比较慢，所以才出现了服务端渲染。

但服务端渲染带来的是无法保留 SPA 无刷新切换页面的体验。

而在实际场景下，往往只需要对首页进行服务端渲染，其他页面保持 SPA 的体验，所以有了同构应用的诞生。

同构的意思是，一份代码，既可以跑在浏览器端，又可以跑在服务端。

同构的一个核心是在于实现路由同构，比如我们使用 express 作为服务端框架，那么我们需要一份代码来将 express-router 和 react-router/vue-router 的差异抹平。

当我们编写了一份 router 文件，这份文件既可以作为 express-router 的配置，也可以作为 react-router/vue-router 的配置。

比如在客户端我们需要根据 router 来拿到 component 和 store 进行客户端渲染，在服务端我们依然要根据 router 来拿到 component 和 store 做服务端渲染。

这一步往往在路由中间件里面去初始化 store，拿到组件，将其渲染成字符串给浏览器。

在 nuxt 中，也是使用了路由中间件的形式。

为什么刷新不生效？

因为在服务启动的时候，就已经加载了 state 文件，后续不管怎么刷新页面，都只是在路由中间件里面去使用初始化模块来创建 Store，这个时候日期肯定就停留在发布的那天了。

这里我写了一个简单的 Demo 来帮助了解：

那么如何解决这个问题呢？其实也很简单，我们只需要将日期放到 state 函数里面就行了，每次创建 Store 的时候都会执行 State 函数重新计算。

为什么在浏览器刷新生效？

在浏览器端，刷新的时候 JS 文件都会被重新加载，模块也会被重新执行，日期自然是当前最新的日期。而在 Node 端，这些模块都被加载到了内存里面，所以不会重新执行了。

runInNewContext

但是在本地 dev 模式下，即使把日期放到外面，刷新后也会起效。这是因为本地开发模式开启了 runInNewContext。

nuxt 会从 nuxt.config.js 里面读取了 runInNewContext 判断是否在新的上下文中运行。

这个 runInNewContext 是什么呢？这个 Node 提供的 vm 模块中的一个方法，它可以提供一个 JS 沙盒，允许你在新的上下文中运行代码，从而实现和当前上下文的隔离。有点儿类似于 eval。

Nuxt 底层依然使用了 vue-server-renderer 中的 createBundleRenderer 方法，里面有个 runInNewContext 选项，会判断是否创建一个新的上下文去运行。

官方的解释是，当访问页面的时候，会判断是否使用 runInNewContext 来执行路由 Bundle 文件（Page、Store 等等），这也是为什么开启了这个选项之后就可以生效。

更新另一个问题

最近在给小课加 SSR 的时候，在 Nuxt 里面还遇到一个问题。
那就是在使用 vue-property-decorator 的时候，组件内部使用 fetch 在服务端获取数据后直出，fetch 方法却一直不执行，最后才发现需要用 nuxt-property-decorator，并且在 nuxt.config.js 的 build 选项里面写上这个：

babel: {
      presets({ isServer }) {
        return [
          [
            "@nuxt/babel-preset-app", { loose: true }
          ]
        ]
      }
    },

2018年过得浑浑噩噩，在舒适区呆了一整年，没什么值得总结的，还是希望在新的一年能够做得更好吧。

技术

对我来说，工作也是提高技术的一部分，所以这两个放到一块说。
技术上，在2018年进步不小，但技术栈依然局限在react上，对服务端和http懂得依然很少。所以在2019年，我的主要精力会放到nodejs和webpack、http上面，技术栈慢慢往全栈上面转。
学习之余，希望自己能够参与一些开源项目，或者自己搞一个开源项目，不管是UI组件库还是工具库都可以。

工作上自然没啥好说的啦~希望能够保持对工作的热情，做自己喜欢做的事情，希望能够升职加薪，毕竟现在已经被一起毕业的同学甩在身后了。

生活

厨艺

还记得去年年底回家的时候，我信心满满地要给大家做个大盘鸡，结果最后失败的非常尴尬哈哈哈。
18年在厨艺上面有了很显著的进步，对鸡精、盐、糖、五香粉等调味剂有了进一步的认识，但是味道和卖相还是达不到餐馆里面的水平，希望今年在厨艺上面有进一步的突破。

健康

临近年末，天气越来越冷，胃痛也越来越多，希望明年能多注意一下饮食，保持好的健康，不想再被病痛折磨了。
关于健身，不做强制要求了，只希望自己能够自觉的保持锻炼的习惯，稍微把体重减下去一些，不想当个小胖子了。

写作

最近一个月天天加班，身心俱惫，也让我不得不中断学习和阅读。
在19年要继续看一些写作方面的书，多看一些散文和小说，争取能写出几篇短篇小说来。培养写作的爱好，为以后的人生增加更多地选择。

理财

17年看过《富爸爸穷爸爸》后就没有看过关于理财方面的书了。18年炒虚拟货币损失惨重，亏了3w左右吧，我也一直不敢和父母说这个，毕竟这也是我交的学费。
这个社会是非常真实的，没有钱什么都做不成。所以19年除了学习，最重要的就是赚钱赚钱赚钱，一方面希望我能和艾老师、叶佳他们取取经，学习一下流量变现，另一方面就是控制支出，多攒一些前期的资本。

书籍

虽说不应该给自己立flag，但还是要有个小目标。

技术

1. 图解http
2. 计算机网络：自顶向下方法
3. 大话数据结构
4. 剑指offer
5. js设计模式与实践
6. 代码大全2

散文和小说

1. 给青年的二十七堂文学课
2. 文心
3. 文章自在
4. 文章例话
5. 完全写作指南
6. 朱自清散文集
7. 梁实秋散文集
8. 沈从文散文
9. 月亮与六便士

理财

1. 富爸爸财务自由之路
2. 财务自由之路
3. 门口的野蛮人
4. 区块链：从数字货币到信用社会

前言

很多前端开发都知道面向对象编程（OOP），却比较少了解 AOP（面向切面编程）这个概念。如果你有使用过 Spring 或者 Nestjs 之类的框架，那就已经接触过 AOP 了。
AOP 是 OOP 的一种补充，前面介绍过的装饰器和 Proxy 都是可以实现 AOP 的一种方式，这也是为什么我把这节放到后面才来讲。
本节课将会重点介绍 AOP（面向切面编程）、IOC（控制反转）和 DI（依赖注入）、Middleware（中间件）相关的概念与实践。

什么是 AOP？

面向切面编程

AOP 是通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。
AOP 实际是 GoF 设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，提高代码的灵活性和可扩展性，AOP可以说也是这种目标的一种实现。

在面向对象中，我们强调单一职责原则和封装，于是我们用不同的类来设计不同的方法，这样代码就分散到一个个类中，降低了复杂度，也提高了类的可重用。

class Cat {
    eat() {}
}
class Dog {
    eat() {}
}
class Duck {
    eat() {}
}

这样看起来很完美，只是有一个问题。那就是如果有一个功能，在所有的类中都需要用到该怎么办？这种设计方式是不是增加了代码的重复性呢？比如我们需要打印出不同动物觅食的信息。
你可能会想到，我再把这部分功能提出来，放到一个新的类 class Logger 里面，在其他类需要的时候调用不就好了吗？

class Logger {
    log() {}
}
class Cat {
    eat() {
        new Logger().log()
    }
}
class Dog {
    eat() {
        new Logger().log()
    }
}

可是这样会让不同的类耦合到一起啊，增加了类之间的耦合度。比如哪天删掉了 Logger 类的 log 方法，那么耦合了 Logger 类的所有类岂不是也要跟着一起修改？
好的软件设计不仅需要降低代码复杂度，也应该减少模块之间的耦合度。
那么有没有一种好的办法解决上面的问题呢？怎么才能让我们随心所欲的在代码中增加新的功能呢？
这就要面向切面（AOP）编程登场了。
切面，可以看做是横切进去的一个平面。通常可以将一些与主业务逻辑无关的代码抽离出来，比如日志、鉴权等等，做成一个个切面，每次调用对应方法的时候都要经过这些切面，如下图所示：

关于如何实现 AOP 没有一种特定的方式，你可以用你喜欢的方式来。

• 用代理模式可以吗？

• 可以。
• 用 Proxy 可以吗？
• 当然可以。
• 用装饰器呢？
• 也可以。

对于面向切面编程，需要关注如下几点：

1. 切面不是 OOP 的替代，而是对 OOP 的一种补充，用于改进 OOP。
2. 切面是主业务之外的、分散在不同类和模块中的横切关注点，即公共部分。
3. 如何从业务中提取出横切关注点是面向切面编程的重要核心。

经典的 before 和 after

针对上面这个例子，可以修改函数的原型，这也是比较常用的一种方式，增加 before 和 after 两个方法。

Function.prototype.after = function (action) {
    const func = this;
    return function () {
        const result = func.apply(this, arguments);
        action.apply(this, arguments);
        return result;
    };
};
Function.prototype.before = function (action) {
    const func = this;
    return function () {
        action.apply(this, arguments);
        return func.apply(this, arguments);
    };
};

因此，上面在执行 eat 方法的时候也可以对其进行改造。

const log = () => {}
const cat = new Cat();
cat.eat = cat.eat.after(log);
cat.eat();

代理模式

第一种方法，可以使用代理模式可以解决上面的问题。只需要创建一个代理类，在这个类里面去执行 eat 方法就好了。

class ProxyLogger {
    constructor(animal) {
        this.animal = animal;
    }
    log() {}
    eat() {
        this.target.eat();
        this.log();
    }
}
const proxyCat = new ProxyLogger(new Cat());
proxyCat.eat();

即使这个 ProxyLogger 类的 log 方法之后修改了，也不会影响其他几个类的内容。

Proxy

你可能会觉得使用代理模式需要增加新的类，而且每次都要去 new 这个类，不如用 Proxy 试试吧。
通过 Proxy 来代理类上面的 eat 方法，在执行 eat 方法之后去插入执行 log 方法。

const ProxyLog = (targetClass) => {
    const log = () => {} // log 方法
    const prototype = targetClass.prototype;
    Object.getOwnPropertyNames(prototype).forEach((name) => {
    if (name === 'eat') {
        prototype[name] = new Proxy(prototype[name], {
        apply(target, context, args) {
            target.apply(context, args)
            log()
        }
    })
    }
 })
}
ProxyLog(Cat);
new Cat().eat();

可能你会说，我不想只打印 eat 方法的参数啊，我还想打印其他的方法呢？其实这个可以用高阶函数来扩展一下。

const ProxyLog = (targetClass) => (targetFunc) => {
    const log = () => {} // log 方法
    const prototype = targetClass.prototype;
    Object.getOwnPropertyNames(prototype).forEach((name) => {
    if (name === targetFunc) {
        prototype[name] = new Proxy(prototype[name], {
        apply(target, context, args) {
            target.apply(context, args)
            log()
        }
    })
    }
 })
}
ProxyLog(Cat)('eat');
ProxyLog(Cat)('meow');

装饰器

上节课我们讲过 Python 中的登录鉴权的实现，那是使用装饰器来实现 AOP 的一种方式。

def auth(func):
    def inner(request,*args,**kwargs):
        v = request.COOKIES.get('user')
        if not v:
            return redirect('/login')
        return func(request, *args,**kwargs)
    return inner

@auth
def index(request):
    user = request.COOKIES.get("user")
    return render(request,"index.html",{"current_user": user})

装饰器有个好处就是可以使得代码看起来更加简洁、易读。上面的例子用装饰器来实现后就会更加优雅。

const logger = (target, name, descriptor) => {
    const log = () => {} // 打印信息
    const func = descriptor.value;
    if (typeof func === 'function') {
        descriptor.value = function(...args) {
            const results = func.apply(this, args);
            log();
            return results;
        }
    }
}
class Cat {
    @logger eat() {}
}
class Dog {
    @logger eat() {}
}

中间件

如果你有使用过 express/koa 或者 redux 这些技术，对中间件这个概念一定不会陌生吧。
前端的中间件技术类似于可以自由组合、自由插拔的插件机制，你可以使用多个中间件去帮完成一些与主业务无关的任务。
图示为 koa 的洋葱模型：

请求进来的时候，会经过一个个中间件方法，这些中间件方法会对请求进行一些处理，然后返回最终的结果，这一点儿和 AOP 很类似。

koa 中间件

以 koa 中的中间件为例子。
一般在初始化 koa 实例后，我们使用 use 方法去加载中间件（middleware），使用数组来保存中间件，中间件的执行顺序决定于 use 的调用顺序。
而每个中间件方法都有 ctx 和 next 两个参数。ctx 代表上下文对象，而 next 则是 koa-compose 定义的中间件方法。
在中间件方法中通过 next 方法可以去执行下一个中间件方法。每个请求进来的时候都会经过 use 中的这两个方法，最终打印出来 1、2、3。

const Koa = require('koa')
const app = new Koa()
app.use((ctx, next) => {
    console.log(1)
    next()
    console.log(3)
})
app.use((ctx) => {
    console.log(2)
})
app.listen(3000)

这种形式其实和前面讲过的 generator 有一些类似，都是需要去调用 next 才能执行下一步。

redux 中间件

redux 中也提供了中间件的形式，允许你在创建 store 的时候添加中间件去处理每次 dispatch 进来的 action。
比如大名鼎鼎的 redux-logger 和 redux-thunk，前者打印每次 action 的相关信息，后者则是改造了 action，使其支持异步请求。
我们都知道，redux 原本只支持同步的 action。以一个请求为例子，每次请求前设置 loading 状态为 true，请求结束后设置为 false，即：

const open = () => {
    return {
        type: 'OPEN',
        payload: true
    }
}
const close = () => {
    return {
        type: 'CLOSE',
        payload: false
    }
}

如果不依赖中间件，该怎么去调用这两个方法呢？可以直接在 react 组件中去调用。

class App extends React.Component {
    componentDidMount() {
        this.fetchList();
    }
    fetchList = () => {
        dispatch(open());
        await fetch('/list');
        dispatch(close());
    }
}

但是如果应用中很多组件都会用到这个请求，那该怎么办呢？当然可以将这个方法从组件中剥离出来放到公共方法中，但是 redux 提供了中间件去处理这种场景。

// actions.js
const fetchList = (dispatch) => async () => {
    dispatch(open());
    await fetch('/list');
    dispatch(close());
}
// App.jsx
class App extends React.Component {
    componentDidMount() {
        this.props.fetchList();
    }
}

上面用到的就是 redux-thunk 这个中间件，它对 dispatch 传入的参数进行了处理，使其支持返回一个函数。
redux-thunk 的主要源码如下：

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => next => action => {
    if (typeof action === 'function') {
      return action(dispatch, getState, extraArgument);
    }
    return next(action);
  };
}

如果传给 dispatch 的是一个函数，那么就将 dispatch、getState 等参数传入并执行。否则就不做处理，直接将 action 传给下一个中间件。

控制反转

在开始之前，先从一个猫吃老鼠的例子说起。

class Cat {
    constructor() {
        this.food = new Mice();
    }
    eat() {
       console.log('The cat eats', this.food); 
    }
}

上面乍一看是没问题的，这么简单的几行代码会有啥问题呢？
但仔细分析一下，主要问题有这两个：

1. 如果想要修改 food 的生成方式，就要到 Cat 类里面进行修改。
2. 如果 Mice 类初始化比较耗时，那么也会导致 Cat 类初始化耗时。
   简单来说，就是 Cat 和 Mice 这两个类互相依赖，耦合到了一起，需要想办法将其分开。

class Cat {
    constructor(mice) {
        this.food = mice;
    }
    eat() {
       console.log('The cat eats', this.food); 
    }
}

所以可以将实例化的过程放到类外面，传给构造函数，这样两个类就不会耦合到一起了。
IoC（Inversion of Control），中文含义是“控制反转”，它是面向对象编程中的一种设计原则。在软件开发中，IoC 意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。

Promise

前面讲解过 Promise 内容的时候，有提到过信任问题。由于回调函数调用是依赖于第三方模块的，我们无法知道它会被调多少次，这样就可能会出现问题。

// 无法得知 callCamera 的实现
callCamera(function() {
    console.log("调用摄像头成功")
})

而 Promise 则是将控制权交到了使用者手里，这样就可以避免受制于第三方模块的实现，我可以自己规定调用几次。

callCamera().then(() => {
    console.log("调用摄像头成功")
})

render props

在 React 里面也有类似控制反转的概念，大名鼎鼎的 render props 就是其中一种。
以轮播图为例子，轮播图主要是渲染其中的图片列表，所以可以这样设计。

<Swiper>
    <img src="x1" />
    <img src="x2" />
    <img src="x3" />
</Swiper>

但是你无法得知 Swiper 组件会对你传入的 img 怎么做渲染，除非去看源码。但通过 render props 的形式，就可以由你自己控制来怎么渲染这些图片。

<Swiper list={list} 
    renderList={(item, index) => (
        <img src={item.src} key={item.id} />
    )} 
/>

依赖注入

依赖注入和控制反转的关系

来重温一下前面的《Javascript 面向对象精读》这篇文章，我们有提到过“依赖倒置原则（Dependence Inversion Principle）”。
依赖倒置原则要求程序依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。
从字面意思来理解，控制反转意味着控制权反转，就是将控制权交出去。
那么是哪方面的控制被反转了呢？一个叫 Martin Fowler 的人经过分析得出，获取依赖对象的过程被反转了。
比如上面例子中的 food，原本控制权在 Cat 类里面，修改之后 Cat 将控制权交了出去，获得依赖对象的过程从自身管理变为了由 IOC 容器主动注入。
他给控制反转起了另一个名字，即依赖注入（Dependency Injection）。依赖注入就是在 IoC 容器运行期间将依赖动态的注入到对象中。

redux 中的依赖注入

在 mobx 和 redux 中都有注入的概念，通过 inject/connect 方法，将组件需要的状态和方法都注入进去。

// redux
@connect(mapStateToProps, mapDispatchToProps)
class App extends React.Component {}

// mobx
@inject(({ store }) => ({
    // ...
}))
class App extends React.Component {}

依赖注入的好处是对外部依赖比较清晰，便于维护。在 nestjs 中到处都能看到依赖注入的实例。

@Module({
    controllers: [ UsersController ],
    components: [ UsersService, ChatGateway ],
})
export class UsersModule implements NestModule {
    constructor(private usersService: UsersService) {}
}

依赖注入的好处就是将两个对象解耦，通过一个 IoC 容器来将依赖的数据注入到另一个对象之中，这个 IoC 容器就起了桥接的作用。

推荐阅读

1. 依赖注入那些事儿
   
2. 深度理解依赖注入
3. 前端需要知道的 依赖注入(Dependency Injection, DI)
   

rex

基于redux改进后的状态管理库 —— rex

设计**

在使用了mobx之后，我深深爱上了mobx那种面向对象创建store的**，对redux的view -> dispatch -> action -> reducer -> store -> view的形式深恶痛绝，于是就开始思考如果用class来创建store的话会怎么样？
于是，rex就诞生了。

state、action

装饰器state用来包裹需要监听的状态，而action则是包裹改变state的函数，在外部调用action包裹方法的时候，内部会自动调用dispatch函数，以确保通知view层状态发生了变化。
如果不用state包裹的属性，那么就会当做一个私有属性来处理，不会出现在store中。

BaseStore

BaseStore是一个基础类，在BaseStore中封装了很多私有函数，用于处理一些底层的逻辑。创建store的时候一定要继承这个基础的BaseStore类，类与类之间可以互相组合。

使用方法

// 如何创建一个store
import {
    action,
    state,
    BaseStore
} from 'rex';
class Counter extends BaseStore {
    @state count = 0;
    @action
    increase() {
        this.count += 1;
    }
    @action
    decrease() {
        this.count -= 1;
    }
}
const counter = Counter.createStore();
export default counter;

// 如何结合react-redux使用
ReactDOM.render(
  <Provider store={counter}>
    <App />
  </Provider>,
  document.getElementById('app')
)

export default connect(state => ({ 
    count: state.count,
    increase: state.increase,
    decrease: state.decrease
}))(props => 
  <div>
    <button onClick={() => props.increase()}>+</button>
    {props.count}
    <button onClick={() => props.decrease()}>-</button>
  </div>
)

和redux的区别

rex的思路和redux并没有本质区别，只是在用法上有一些细微差异。
store的创建必须通过class，而不是reducer。通过action装饰器包裹的函数在执行时会自动使用dispatch，不用手动调用dispatch，将dispatch -> action -> reducer简化为了一步。

结论

这个库在一定程度上借鉴了redux和mobx的**，将其两者做了一个结合，使用面向对象的形式来写redux，各方面和redux保持一致，但是操作却简化了不少。

前言

上一篇介绍了移动端开发的相关技术，这一篇主要是从 Hybrid 开发的 JS Bridge 通信讲起。

顾名思义，JS Bridge 的意思就是桥，这是一个连接 JS 和 Native 的桥接，也是 Hybrid App 里面的核心。一般分为 JS 调用 Native 和 Native 主动调用 JS 两种形式。

URL Scheme

URL Scheme 是一种特殊的 URL，一般用于在 Web 端唤醒 App，甚至跳转到 App 的某个页面，比如在某个手机网站上付款的时候，可以直接拉起支付宝支付页面。

这里有个小例子，你可以在浏览器里面直接输入 weixin://，系统就会提示你是否要打开微信。输入 mqq:// 就会帮你唤起手机 QQ。

这里有个常用 App URL Scheme 汇总：URL Schemes 收集整理

在手机里面打开这个页面后点击这里，就会提示你是否要打开微信。

我们常说的 Deeplink 一般也是基于 URL Scheme 来实现的。一个 URI 的组成结构如下：

URI = scheme:[//authority]path[?query][#fragment]
// scheme     = http
// authority  = www.baidu.com
// path       = /link
// query      = url=xxxxx
authority = [userinfo@]host[:port]

除了 http/https 这两个常见的协议，还可以自定义协议。借用维基百科的一张图：

通常情况下，App 安装后会在手机系统上注册一个 Scheme，比如 weixin:// 这种，所以我们在手机浏览器里面访问这个 scheme 地址，系统就会唤起我们的 App。

一般在 Android 里面需要到 AndroidManifest.xml 文件中去注册 Scheme：

<activity
    android:name=".login.dispatch.DispatchActivity"
    android:launchMode="singleTask"
    android:theme="@style/AppDispatchTheme">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="taobao" />
        <data android:host="xxx" />
        <data android:path="/goods" />
    </intent-filter>
</activity>

在 iOS 中需要在 Xcode 里面注册，有一些已经是系统使用的不应该使用，比如 Maps、YouTube、Music。具体可以参考苹果开发者官网文档：Defining a Custom URL Scheme for Your App

JS 调用 Native

在 iOS 里面又需要区分 UIWebView 和 WKWebView 两种 WebView：

WKWebView 是 iOS8 之后出现的，目的是取代笨重的 UIWebView，它占用内存更少，大概是 UIWebView 的 1/3，支持更好的 HTML5 特性，性能更加强大。
但也有一些缺点，比如不支持缓存，需要自己注入 Cookie，发送 POST 请求的时候带不了参数，拦截 POST 请求的时候无法解析参数等等。

JS 调用 Native 通信大致有三种方法：

1. 拦截 Scheme
2. 弹窗拦截
3. 注入 JS 上下文

这三种方式总体上各有利弊，下面会一一介绍。

拦截 Scheme

仔细思考一下，如果是 JS 和 Java 之间传递数据，我们该怎么做呢？
对于前端开发来说，调 Ajax 请求接口是最常见的需求了。不管对方是 Java 还是 Python，我们都可以通过 http/https 接口来获取数据。实际上这个流程和 JSONP 更加类似。

已知客户端是可以拦截请求的，那么可不可以在这个上面做文章呢？

如果我们请求一个不存在的地址，上面带了一些参数，通过参数告诉客户端我们需要调用的功能呢？

比如我要调用扫码功能：

axios.get('http://xxxx?func=scan&callback_id=yyyy')

客户端可以拦截这个请求，去解析参数上面的 func 来判断当前需要调起哪个功能。客户端调起扫码功能之后，会获取 WebView 上面的 callbacks 对象，根据 callback_id 回调它。

所以基于上面的例子，我们可以把域名和路径当做通信标识，参数里面的 func 当做指令，callback_id 当做回调函数，其他参数当做数据传递。对于不满足条件的 http 请求不应该拦截。

当然了，现在主流的方式是前面我们看到的自定义 Scheme 协议，以这个为通信标识，域名和路径当做指令。

这种方式的好处就是 iOS6 以前只支持这种方式，兼容性比较好。

JS 侧

我们有很多种方法可以发起请求，目前使用最广泛的是 iframe 跳转：

1. 使用 a 标签跳转

<a href="taobao://">点击我打开淘宝</a>

2. 重定向

location.href = "taobao://"

3. iframe 跳转

const iframe = document.createElement("iframe");
iframe.src = "taobao://"
iframe.style.display = "none"
document.body.appendChild(iframe)

Android 侧

在 Android 侧可以用 shouldOverrideUrlLoading 来拦截 url 请求。

@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
    if (url.startsWith("taobao")) {
        // 拿到调用路径后解析调用的指令和参数，根据这些去调用 Native 方法
        return true;
    }
}

iOS 侧

在 iOS 侧需要区分 UIWebView 和 WKWebView 两种方式。
在 UIWebView 中：

- (BOOL)shouldStartLoadWithRequest:(NSURLRequest *)request
                    navigationType:(BPWebViewNavigationType)navigationType
{

    if (xxx) {
        // 拿到调用路径后解析调用的指令和参数，根据这些去调用 Native 方法
        return NO;
    }

    return [super shouldStartLoadWithRequest:request navigationType:navigationType];
}

在 WKWebView 中：

- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(nonnull WKNavigationAction *)navigationAction decisionHandler:(nonnull void (^)(WKNavigationActionPolicy))decisionHandler
{
    if(xxx) {
        // 拿到调用路径后解析调用的指令和参数，根据这些去调用 Native 方法
        BLOCK_EXEC(decisionHandler, WKNavigationActionPolicyCancel);
    } else {
        BLOCK_EXEC(decisionHandler, WKNavigationActionPolicyAllow);
    }

    [self.webView.URLLoader webView:webView decidedPolicy:policy forNavigationAction:navigationAction];
}

目前不建议只使用拦截 URL Scheme 解析参数的形式，主要存在几个问题。

1. 连续续调用 location.href 会出现消息丢失，因为 WebView 限制了连续跳转，会过滤掉后续的请求。
2. URL 会有长度限制，一旦过长就会出现信息丢失
   因此，类似 WebViewJavaScriptBridge 这类库，就结合了注入 API 的形式一起使用，这也是我们这边目前使用的方式，后面会介绍一下。

弹窗拦截

Android 实现

这种方式是利用弹窗会触发 WebView 相应事件来拦截的。一般是在 setWebChromeClient 里面的 onJsAlert、onJsConfirm、onJsPrompt 方法拦截并解析他们传来的消息。

// 拦截 Prompt
@Override
public boolean onJsPrompt(WebView view, String url, String message, String defaultValue, JsPromptResult result) {
       if (xxx) {
        // 解析 message 的值，调用对应方法
       }
       return super.onJsPrompt(view, url, message, defaultValue, result);
   }
// 拦截 Confirm
@Override
public boolean onJsConfirm(WebView view, String url, String message, JsResult result) {
       return super.onJsConfirm(view, url, message, result);
   }
// 拦截 Alert
@Override
public boolean onJsAlert(WebView view, String url, String message, JsResult result) {
       return super.onJsAlert(view, url, message, result);
   }

iOS 实现

我们以 WKWebView 为例：

+ (void)webViewRunJavaScriptTextInputPanelWithPrompt:(NSString *)prompt
    defaultText:(NSString *)defaultText
    completionHandler:(void (^)(NSString * _Nullable))completionHandler
{
    /** Triggered by JS:
    var person = prompt("Please enter your name", "Harry Potter");
    if (person == null || person == "") {
       txt = "User cancelled the prompt.";
    } else {
       txt = "Hello " + person + "! How are you today?";
    }
    */
    if (xxx) {
        BLOCK_EXEC(completionHandler, text);
    } else {
        BLOCK_EXEC(completionHandler, nil);
    }
 }

这种方式的缺点就是在 iOS 上面 UIWebView 不支持，但是 WKWebView 又有更好的 scriptMessageHandler，比较尴尬。

注入上下文

前面我们有讲过在 iOS 中内置了 JavaScriptCore 这个框架，可以实现执行 JS 以及注入 Native 对象等功能。

这种方式不依赖拦截，主要是通过 WebView 向 JS 的上下文注入对象和方法，可以让 JS 直接调用原生。

PS：iOS 中的 Block 是 OC 对于闭包的实现，它本质上是个对象，定义 JS 里面的函数。

iOS UIWebView

iOS 侧代码：

// 获取 JS 上下文
JSContext *context = [webview valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];
// 注入 Block
context[@"callHandler"] = ^(JSValue * data) {
    // 处理调用方法和参数
    // 调用 Native 功能
    // 回调 JS Callback
}

JS 代码：

window.callHandler({
    type: "scan",
    data: "",
    callback: function(data) {
    }
});

这种方式的牛逼之处在于，JS 调用是同步的，可以立马拿到返回值。

我们也不再需要像拦截方式一样，每次传值都要把对象做 JSON.stringify，可以直接传 JSON 过去，也支持直接传一个函数过去。

iOS WKWebView

WKWebView 里面通过 addScriptMessageHandler 来注入对象到 JS 上下文，可以在 WebView 销毁的时候调用 removeScriptMessageHandler 来销毁这个对象。
前端调用注入的原生方法之后，可以通过 didReceiveScriptMessage 来接收前端传过来的参数。

WKWebView *wkWebView = [[WKWebView alloc] init];
WKWebViewConfiguration *configuration = wkWebView.configuration;
WKUserContentController *userCC = configuration.userContentController;

// 注入对象
[userCC addScriptMessageHandler:self name:@"nativeObj"];
// 清除对象
[userCC removeScriptMessageHandler:self name:@"nativeObj"];

// 客户端处理前端调用
- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message
{
    // 获取前端传来的参数
    NSDictionary *msgBody = message.body;
    // 如果是 nativeObj 就进行相应处理
    if (![message.name isEqualToString:@"nativeObj"]) {
        // 
        return;
    }
}

使用 addScriptMessageHandler 注入的对象实际上只有一个 postMessage 方法，无法调用更多自定义方法。前端的调用方式如下：

window.webkit.messageHandlers.nativeObj.postMessage(data);

需要注意的是，这种方式要求 iOS8 及以上，而且返回不是同步的。和 UIWebView 一样的是，也支持直接传 JSON 对象，不需要 stringify。

Android addJavascriptInterface

安卓4.2之前注入 JS 一般是使用 addJavascriptInterface ，和前面的 addScriptMessageHandler 有一些类似，但又没有它的限制。

public void addJavascriptInterface() {
        mWebView.addJavascriptInterface(new DatePickerJSBridge(), "DatePickerBridge");
    }
private class PickerJSBridge {
    public void _pick(...) {
    }
}

在 JS 里面调用：

window.DatePickerBridge._pick(...)

但这种方案有一定风险，可以参考这篇文章：WebView中接口隐患与手机挂马利用
在 Android4.2 之后提供了 @JavascriptInterface 注解，暴露给 JS 的方法必须要带上这个。
所以前面的 _pick 方法需要带上这个注解。

private class PickerJSBridge {
    @JavascriptInterface
    public void _pick(...) {
    }
}

Native 调用 JS

Native 调用 JS 一般就是直接 JS 代码字符串，有些类似我们调用 JS 中的 eval 去执行一串代码。一般有 loadUrl、evaluateJavascript 等几种方法，这里逐一介绍。
但是不管哪种方式，客户端都只能拿到挂载到 window 对象上面的属性和方法。

Android

在 Android 里面需要区分版本，在安卓4.4之前的版本支持 loadUrl，使用方式类似我们在 a 标签的 href 里面写 JS 脚本一样，都是javascript:xxx 的形式。这种方式无法直接获取返回值。

webView.loadUrl("javascript:foo()")

在安卓4.4以上的版本一般使用 evaluateJavascript 这个 API 来调用。这里需要判断一下版本。

if (Build.VERSION.SDK_INT > 19) //see what wrapper we have
{
    webView.evaluateJavascript("javascript:foo()", null);
} else {
    webView.loadUrl("javascript:foo()");
}

UIWebView

在 iOS 的 UIWebView 里面使用 stringByEvaluatingJavaScriptFromString 来调用 JS 代码。这种方式是同步的，会阻塞线程。

results = [self.webView stringByEvaluatingJavaScriptFromString:"foo()"];

WKWebView

WKWebView 可以使用 evaluateJavaScript 方法来调用 JS 代码。

[self.webView evaluateJavaScript:@"document.body.offsetHeight;" completionHandler:^(id _Nullable response, NSError * _Nullable error) {
    // 获取返回值 response
    }];

JS Bridge 设计

前面讲完了 JS 和 Native 互调的所有方法，这里来介绍一下我们这边 JS Bridge 的设计吧。
我们这边的 JS Bridge 通信是基于 WebViewJavascriptBridge 这个库来实现的。主要是结合 Scheme 协议+上下文注入来做。考虑到 Android 和 iOS 不一样的通信方式，这里进行了封装，保证提供给外部的 API 一致。
具体功能的调用我们封装成了 npm 包，下面的是几个基础 API：

1. callHandler(name, params, callback)：这个是调用 Native 功能的方法，传模块名、参数、回调函数给 Native。
2. hasHandler(name)：这个是检查客户端是否支持某个功能的调用。
3. registerHandler(name)：这个是提前注册一个函数，等待 Native 回调，比如 pageDidBack 这种场景。

那么这几个 API 又是如何实现的呢？这里 Android 和 iOS 封装不一致，应当分开来说。

Android Bridge

前面我们有说过安卓可以通过 @JavascriptInterface 注解来将对象和方法暴露给 JS。所以这里的几个方法都是通过注解暴露给 JS 来调用的，在 JS 层面做了一些兼容处理。

hasHandler

首先最简单的是这个 hasHandler，就是在客户端里面维护一张表（其实我们是写死的），里面有支持的 Bridge 模块信息，只需要用 switch...case 判断一下就行了。

@JavascriptInterface
public boolean hasHandler(String cmd) {
        switch (cmd) {
            case xxx:
            case yyy:
            case zzz:
                return true;
        }
        return false;
    }

callHandler

然后我们来看 callHandler 这个方法，它是提供 JS 调用 Native 功能的方法。在调用这个方法之前，我们一般需要先判断一下 Native 是否支持这个功能。

function callHandler(name, params, callback) {
    if (!window.WebViewJavascriptBridge.hasHandler(name)) {
    }
}

如果 Native 没有支持这个 Bridge，我们就需要对回调进行兼容性处理。这个兼容性处理包括两个方面，一个是功能方面，一个是 callback 的默认回参。

比如我们调用 Native 的弹窗功能，如果客户端没支持这个 Bridge，或者我们是在浏览器里面打开的这个页面，此时应该退出到使用 Web 的 alert 弹窗。对于 callback，我们可以默认给传个 0，表示当前不支持这个功能。

假设这个 alert 的 bridge 接收两个参数，分别是 title 和 content，那么此时就应该使用浏览器自带的 alert 展示出来。

function fallback(params, callback) {
    let content = `${params.title}\n{params.content}`
    window.alert(content);
    callback && callback(0)
}

这个 fallback 函数我们希望能够更加通用，每个调用方法都应该有自己的 fallback 函数，所以前面的 callHandler 应该设计成这样：

function callHandler(name, params, fallback) {
    return function(...rest, callback) {
        const paramsList = {};
        for (let i = 0; i < params.length; i++) {
            paramsList[params] = rest[i];
        }
        if (!callback) {
            callback = function(result) {};
        }
        if (fallback && !window.WebViewJavascriptBridge.hasHandler(name))) {
            fallback(paramsList, callback);
        } else {
            window.WebViewJavascriptBridge.callHandler(name, params, callback);
        }
    }
}

我们可以基于这个函数封装一些功能方法，比如前面的 alert：

function fallback(params, callback) {
    let content = `${params.title}\n{params.content}`
    window.alert(content);
    callback && callback(0)
}

function alert(
  title,
  content,
  cb: any
) {
  return callHandler(
    'alert',
    ['title', 'content'],
    fallback
  )(title, content, cb);
}
alert(`this is title`, `hahaha`, function() {
    console.log('success')
})

具体效果类似下面这种，这是从 Google 上随便找的一张图（侵删）：

那么客户端又如何实现回调 callback 函数的呢？前面说过，客户端想调用 JS 方法，只能调用挂载到 window 对象上面的。

因此，这里使用了一种很巧妙的方法，实际上 callback 函数依然是 JS 执行的。在调用 Native 之前，我们可以先将 callback 函数和一个 uniqueId 映射起来，然后存在 JS 本地。我们只需要将 callbackId 传给 Native 就行了。

function callHandler(name, data, callback) {
    const id = `cb_${uniqueId++}_${new Date().getTime()}`;
    callbacks[id] = callback;
    window.bridge.send(name, JSON.stringify(data), id)
}

在客户端这里，当 send 方法接收到参数之后，会执行相应功能，然后使用 webView.loadUrl 主动调用前端的一个接收函数。

@JavascriptInterface
public void send(final String cmd, String data, final String callbackId) {
    // 获取数据，根据 cmd 来调用对应功能
    // 调用结束后，回调前端 callback
    String js = String.format("javascript: window.bridge.onReceive(\'%1$s\', \'%2$s\');", callbackId, result.toDataString());
    webView.loadUrl(js);
}

所以 JS 需要事前定义好这个 onReceive 方法，它接收一个 callbackId 和一个 result。

window.bridge.onReceive = function(callbackId, result) {
    let params = {};
    try {
        params = JSON.parse(result)
    } catch (err) {
        //
    }
    if (callbackId) {
        const callback = callbacks[callbackId];
        callback(params)
        delete callbacks[callbackId];
    }
}

大致流程如下：

registerHandler

注册的流程比较简单，也是我们把 callback 函数事先存到一个 messageHandler 对象里面，不过这次的 key 不再是一个随机的 id，而是 name。

function registerHandler(handlerName, callback) {
    if (!messageHandlers[handlerName]) {
      messageHandlers[handlerName] = [handler];
    } else {
      // 支持注册多个 handler
      messageHandlers[handlerName].push(handler);
    }
}
// 检查是否有这个注册可以直接检查 messageHandlers 里面是否有
function hasRegisteredHandler(handlerName) {
    let has = false;
    try {
      has = !!messageHandlers[handlerName];
    } catch (exception) {}
      return has;
    }

这里不像 callHandler 需要主动调用 window.bridge.send 去通知客户端，只需要等客户端到了相应的时机来调用 window.bridge.onReceive 就行了。
所以这里还需要改造一下 onReceive 方法。由于不再会有 callbackId 了，所以客户端可以传个空值，然后将 handlerName 放到 result 里面。

window.bridge.onReceive = function(callbackId, result) {
    let params = {};
    try {
        params = JSON.parse(result)
    } catch (err) {
        //
    }
    if (callbackId) {
        const callback = callbacks[callbackId];
        callback(params)
        delete callbacks[callbackId];
    } else if (params.handlerName)(
        // 可能注册了多个
        const handlers =  messageHandlers[params.handlerName];
        for (let i = 0; i < handlers.length; i++) {
            try {
                delete params.handlerName;
                handlers[i](params);
            } catch (exception) {
            }
        }
    )
}

这种情况下的流程如下，可以发现完全不需要 JS 调用 Native：

iOS Bridge

讲完了 Android，我们再来讲讲 iOS，原本 iOS 可以和 Android 设计一致，可是由于种种原因导致有不少差异。

iOS 和 Android 中最显著的差异就在于这个 window.bridge.send 方法的实现，Android 里面是直接调用 Native 的方法，iOS 中是通过 URL Scheme 的形式调用。

协议依然是 WebViewJavaScriptBridge 里面的协议，URL Scheme 本身不会传递数据，只是告诉 Native 有新的调用。

然后 Native 会去调用 JS 的方法，获取队列里面所有需要执行的方法。

所以我们需要事先创建好一个 iframe，插入到 DOM 里面，方便后续使用。

const CUSTOM_PROTOCOL_SCHEME = 'wvjbscheme';
const QUEUE_HAS_MESSAGE = '__WVJB_QUEUE_MESSAGE__';
function _createQueueReadyIframe(doc) {
    messagingIframe = doc.createElement('iframe');
    messagingIframe.style.display = 'none';
    messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://' + QUEUE_HAS_MESSAGE;
    doc.documentElement.appendChild(messagingIframe);
  }

callHandler

每次调用的时候只需要复用这个 iframe 就行了。这里是处理 callback 并通知 Native 的代码：

function callHandler(handlerName, data, responseCallback) {
    _doSend({ handlerName: handlerName, data: data }, responseCallback);
  }
function _doSend(
    message,
    callback
  ) {
    if (responseCallback) {
      const callbackId = `cb_${uniqueId++}_${new Date().getTime()}`;
      callbacks[callbackId] = callback;
      message['callbackId'] = callbackId;
    }
    sendMessageQueue.push(message);
    messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://' + QUEUE_HAS_MESSAGE;
  }

通知 Native 之后，它怎么拿到我们的 handlerName 和 data 呢？我们可以实现一个 fetchQueue 的方法。

  function _fetchQueue() {
    const messageQueueString = JSON.stringify(sendMessageQueue);
    sendMessageQueue = [];
    return messageQueueString;
  }

然后将其挂载到 window.WebViewJavascriptBridge 对象上面。

  window.WebViewJavascriptBridge = {
    _fetchQueue: _fetchQueue
  };

这样 iOS 就可以使用 evaluateJavaScript 轻松拿到这个 messageQueue。

- (void)flushMessageQueue
{
    [_webView evaluateJavaScript:@"WebViewJavascriptBridge._fetchQueue();" completionHandler:^(id _Nullable result, NSError * _Nullable error) {
        [self _flushMessageQueue:result];
    }];
}
- (void)_flushMessageQueue:(id)messageQueueObj
{
    // 解析 messageQueueString
    // 根据传入的 handlerName 执行对应操作
}

那么 iOS 又是如何回调 JS 的 callback 函数呢？这个其实和 Android 的 onReceive 是同样的原理。这里可以实现一个 _handleMessageFromObjC 方法，同样挂载到 window.WebViewJavascriptBridge 对象上面，等待 iOS 回调。

function _dispatchMessageFromObjC(messageJSON) {
    const message = JSON.parse(messageJSON);
    if (message.responseId) {
        var responseCallback = callbacks[message.responseId];
        if (!responseCallback) {
          return;
        }
        responseCallback(message.responseData);
        delete callbacks[message.responseId];
     }
}

流程如下：

registerHandler

registerHandler 和 Android 原理是一模一样的，都是提前注册一个事件，等待 iOS 调用，具体就不多讲了，这里直接放代码：

// 注册
function registerHandler(handlerName, handler) {
    if (typeof messageHandlers[handlerName] === 'undefined') {
      messageHandlers[handlerName] = [handler];
    } else {
      messageHandlers[handlerName].push(handler);
    }
  }
// 回调
function _dispatchMessageFromObjC(messageJSON) {
    const message = JSON.parse(messageJSON);
    if (message.responseId) {
        var responseCallback = callbacks[message.responseId];
        if (!responseCallback) {
          return;
        }
        responseCallback(message.responseData);
        delete callbacks[message.responseId];
     } else if (message.handlerName){
        handlers = messageHandlers[message.handlerName];
        for (let i = 0; i < handlers.length; i++) {
          try {
            handlers[i](message.data, responseCallback);
          } catch (exception) {
          }
        }
     }
}

总结

这些就是 Hybrid 里面 JS 和 Native 交互的大致原理，忽略了不少细节，比如初始化 WebViewJavascriptBridge 对象等等，感兴趣的也可以参考一下这个库：JsBridge

俗话说，人靠衣装，佛靠金装。大街上的小姐姐都喜欢把自己打扮得美美的，让你忍不住多看几眼，这就是装饰的作用。

1. 前言

装饰器是最新的 ECMA 中的一个提案，是一种与类（class）相关的语法，用来注释或修改类和类方法。装饰器在 Python 和 Java 等语言中也被大量使用。装饰器是实现 AOP（面向切面）编程的一种重要方式。

下面是一个使用装饰器的简单例子，这个 @readonly 可以将 count 属性设置为只读。可以看出来，装饰器大大提高了代码的简洁性和可读性。

class Person {
    @readonly count = 0;
}

由于浏览器还未支持装饰器，为了让大家能够正常看到效果，这里我使用 Parcel 进行了一下简单的配置，可以去 clone 这个仓库后再来运行本文涉及到的所有例子，仓库地址：learn es6

本文涉及到 Object.defineProperty、高阶函数等知识，如果之前没有了解过相关概念，建议先了解后再来阅读本文。

2. 装饰器模式

在开始讲解装饰器之前，先从经典的装饰器模式说起。装饰器模式是一种结构型设计模式，它允许向一个现有的对象添加新的功能，同时又不改变其结构，是作为对现有类的一个包装。

一般来说，在代码设计中，我们应当遵循「多用组合，少用继承」的原则。通过装饰器模式动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。

2.1 一个英雄联盟的例子

下班回去和朋友愉快地开黑，当我正在用亚索「面对疾风吧」的时候，突然想到，如果让我设计亚索英雄，我该怎么实现呢？

我灵光一闪，那肯定会先设计一个英雄的类。

class Hero {
    attack() {}
}

然后，再实现一个 Yasuo 的类来继承这个 Hero 类。

class Yasuo extends Hero {
    attack() {
        console.log("斩钢闪");
    }
}

我还在想这个问题的时候，队友已经打了大龙，我的亚索身上就出现了大龙 buff 的印记。我突然想到，那该怎么给英雄增加大龙 buff 呢？那增加个大龙 buff 的属性不行吗？

当然不太行，要知道，英雄联盟里面的大龙 buff 是会增加收益的。

嗯，聪明的我已经想到办法了，再继承一次不就好了吗？

class BaronYasuo extends Yasuo {}

厉害了，但是如果亚索身上还有其他 buff 呢？毕竟 LOL 里面是有红 buff、蓝 buff、大龙 buff 等等存在，那岂不是有多少种就要增加多少个类吗？

可以换种思路来思考这个问题，如果把 buff 当做我们身上的衣服。在不同的季节，我们会换上不同的衣服，到了冬天，甚至还会叠加多件衣服。当 buff 消失了，就相当于把这件衣服脱了下来。如下图所示：

衣服对人来说起到装饰的作用，buff 对于亚索来说也只是增强效果。那么，你是不是有思路了呢？
没错，可以创建 Buff 类，传入英雄类后获得一个新的增强后的英雄类。

class RedBuff extends Buff {
    constructor(hero) {
        this.hero = hero;
    }
    // 红buff造成额外伤害
    extraDamage() {
    }
    attack() {
        return this.hero.attack() + this.extraDamage();
    }
}
class BlueBuff extends Buff {
    constructor(hero) {
        this.hero = hero;
    }
    // 技能CD（减10%）
    CDR() {
        return this.hero.CDR() * 0.9;
    }
}
class BaronBuff extends Buff {
    constructor(hero) {
        this.hero = hero;
    }
    // 回城速度缩短一半
    backSpeed() {
        return this.hero.backSpeed * 0.5;
    }
}

定义好所有的 buff 类之后，就可以直接套用到英雄身上，这样看起来是不是清爽了很多呢？这种写法看起来很像函数组合。

const yasuo = new Yasuo();
const redYasuo = new RedBuff(yasuo); // 红buff亚索
const blueYasuo = new BlueBuff(yasuo); // 蓝buff亚索
const redBlueYasuo = new BlueBuff(redYasuo); // 红蓝buff亚索

3. ES7 装饰器

decorator（装饰器）是 ES7 中的一个提案，目前处于 stage-2 阶段，提案地址：JavaScript Decorators。

装饰器与之前讲过的函数组合（compose）以及高阶函数很相似。装饰器使用 @ 作为标识符，被放置在被装饰代码前面。在其他语言中，早就已经有了比较成熟的装饰器方案。

3.1 Python 中的装饰器

先来看一下 Python 中的一个装饰器的例子：

def auth(func):
    def inner(request,*args,**kwargs):
        v = request.COOKIES.get('user')
        if not v:
            return redirect('/login')
        return func(request, *args,**kwargs)
    return inner

@auth
def index(request):
    v = request.COOKIES.get("user")
    return render(request,"index.html",{"current_user":v})

这个 auth 装饰器是通过检查 cookie 来判断用户是否登录的。auth 函数是一个高阶函数，它接收了一个 func 函数作为参数，返回了一个新的 inner 函数。

在 inner 函数中进行 cookie 的检查，由此来判断是跳回登录页面还是继续执行 func 函数。

在所有需要权限验证的函数上，都可以使用这个 auth 装饰器，很简洁明了且无侵入。

3.2 JavaScript 装饰器

JavaScript 中的装饰器和 Python 的装饰器类似，依赖于 Object.defineProperty，一般是用来装饰类、类属性、类方法。

使用装饰器可以做到不直接修改代码，就实现某些功能，做到真正的面向切面编程。这在一定程度上和 Proxy 很相似，但使用起来比 Proxy 会更加简洁。

注意：装饰器目前还处于 stage-2，意味着语法之后也许会有变动。装饰器用于函数、对象等等已经有一些规划，请看：Future built-in decorators

3.3 类装饰器

装饰类的时候，装饰器方法一般会接收一个目标类作为参数。下面是一个给目标类增加静态属性 test 的例子：

const decoratorClass = (targetClass) => {
    targetClass.test = '123'
}
@decoratorClass
class Test {}
Test.test; // '123'

除了可以修改类本身，还可以通过修改原型，给实例增加新属性。下面是给目标类增加 speak 方法的例子：

const withSpeak = (targetClass) => {
    const prototype = targetClass.prototype;
    prototype.speak = function() {
        console.log('I can speak ', this.language);
    }
}
@withSpeak
class Student {
    constructor(language) {
        this.language = language;
    }
}
const student1 = new Student('Chinese');
const student2 = new Student('English');
student1.speak(); // I can speak  Chinese

student2.speak(); // I can speak  Englist

利用高阶函数的属性，还可以给装饰器传参，通过参数来判断对类进行什么处理。

const withLanguage = (language) => (targetClass) => {
    targetClass.prototype.language = language;
}
@withLanguage('Chinese')
class Student {
}
const student = new Student();
student.language; // 'Chinese'

如果你经常编写 react-redux 的代码，那么也会遇到需要将 store 中的数据映射到组件中的情况。connect 是一个高阶组件，它接收了两个函数 mapStateToProps 和 mapDispatchToProps 以及一个组件 App，最终返回了一个增强版的组件。

class App extends React.Component {
}
connect(mapStateToProps, mapDispatchToProps)(App)

有了装饰器之后，connect 的写法可以变得更加优雅。

@connect(mapStateToProps, mapDispatchToProps)
class App extends React.Component {
}

3.4 类属性装饰器

类属性装饰器可以用在类的属性、方法、get/set 函数中，一般会接收三个参数：

1. target：被修饰的类
2. name：类成员的名字
3. descriptor：属性描述符，对象会将这个参数传给 Object.defineProperty

使用类属性装饰器可以做到很多有意思的事情，比如最开始举的那个 readonly 的例子：

function readonly(target, name, descriptor) {
  descriptor.writable = false;
  return descriptor;
}
class Person {
    @readonly name = 'person'
}
const person = new Person();
person.name = 'tom'; 

还可以用来统计一个函数的执行时间，以便于后期做一些性能优化。

function time(target, name, descriptor) {
    const func = descriptor.value;
    if (typeof func === 'function') {
        descriptor.value = function(...args) {
            console.time();
            const results = func.apply(this, args);
            console.timeEnd();
            return results;
        }
    }
}
class Person {
    @time
    say() {
        console.log('hello')
    }
}
const person = new Person();
person.say();

在 react 知名的状态管理库 mobx 中，也通过装饰器来将类属性置为可观察属性，以此来实现响应式编程。

import {
    observable,
    action,
    autorun
} from 'mobx'

class Store {
    @observable count = 1;
    @action
    changeCount(count) {
        this.count = count;
    }
}

const store = new Store();
autorun(() => {
    console.log('count is ', store.count);
})
store.changeCount(10); // 修改 count 的值，会引起 autorun 中的函数自动执行。

3.5 装饰器组合

如果你想要使用多个装饰器，那么该怎么办呢？装饰器是可以叠加的，根据离被装饰类/属性的距离来依次执行。

class Person {
    @time
    @log
    say() {}
}

除此之外，在装饰器的提案中，还出现了一种组合了多种装饰器的装饰器例子。目前还没见到被使用。

通过使用 decorator 来声明一个组合装饰器 xyz，这个装饰器组合了多种装饰器。

decorator @xyz(arg, arg2 {
  @foo @bar(arg) @baz(arg2)
}
@xyz(1, 2) class C { }

和下面这种写法是一样的。

@foo @bar(1) @baz(2)
class C { }

4. 装饰器可以做哪些有意思的事情？

4.1 多重继承

在实现 JavaScript 多重继承的时候，可以使用 mixin 的方式，这里结合装饰器甚至还能更进一步简化 mixin 的使用。

mixin 方法将会接收一个父类列表，用其装饰目标类。我们理想中的用法应该是这样：

@mixin(Parent1, Parent2, Parent3)
class Child {}

和之前实现多重继承的时候实现原理一致，只需要拷贝父类的原型属性和实例属性就可以实现了。

这里创建了一个新的 Mixin 类，来将 mixins 和 targetClass 上面的所有属性都拷贝过去。

const mixin = (...mixins) => (targetClass) => {
  mixins = [targetClass, ...mixins];
  function copyProperties(target, source) {
    for (let key of Reflect.ownKeys(source)) {
      if (key !== 'constructor'
        && key !== 'prototype'
        && key !== 'name'
      ) {
        let desc = Object.getOwnPropertyDescriptor(source, key);
        Object.defineProperty(target, key, desc);
      }
    }
  }
  class Mixin {
    constructor(...args) {
      for (let mixin of mixins) {
        copyProperties(this, new mixin(...args)); // 拷贝实例属性
      }
    }
  }

  for (let mixin of mixins) {
    copyProperties(Mixin, mixin); // 拷贝静态属性
    copyProperties(Mixin.prototype, mixin.prototype); // 拷贝原型属性
  }
  return Mixin;
}

export default mixin

我们来测试一下这个 mixin 方法是否能够正常工作吧。

class Parent1 {
    p1() {
        console.log('this is parent1')
    }
}
class Parent2 {
    p2() {
        console.log('this is parent2')
    }
}
class Parent3 {
    p3() {
        console.log('this is parent3')
    }
}
@mixin(Parent1, Parent2, Parent3)
class Child {
    c1 = () => {
        console.log('this is child')
    }
}
const child = new Child();
console.log(child);

最终在浏览器中打印出来的 child 对象是这样的，证明了这个 mixin 是可以正常工作的。

注意：这里的 Child 类就是前面的 Mixin 类。

也许你会问，为什么还要多创建一个多余的 Mixin 类呢？为什么不能直接修改 targetClass 的 constructor 呢？前面不是讲过 Proxy 可以拦截 constructor 吗？

恭喜你，你已经想到了 Proxy 的一种使用场景。没错，这里用 Proxy 的确会更加优雅。

const mixin = (...mixins) => (targetClass) => {
    function copyProperties(target, source) {
        for (let key of Reflect.ownKeys(source)) {
          if ( key !== 'constructor'
            && key !== 'prototype'
            && key !== 'name'
          ) {
            let desc = Object.getOwnPropertyDescriptor(source, key);
            Object.defineProperty(target, key, desc);
          }
        }
      }
    
      for (let mixin of mixins) {
        copyProperties(targetClass, mixin); // 拷贝静态属性
        copyProperties(targetClass.prototype, mixin.prototype); // 拷贝原型属性
      }
      // 拦截 construct 方法，进行实例属性的拷贝
      return new Proxy(targetClass, {
        construct(target, args) {
          const obj = new target(...args);
          for (let mixin of mixins) {
              copyProperties(obj, new mixin()); // 拷贝实例属性
          }
          return obj;
        }
      });
}

4.2 防抖和节流

以往我们在频繁触发的场景下，为了优化性能，经常会使用到节流函数。下面以 React 组件绑定滚动事件为例子：

class App extends React.Component {
    componentDidMount() {   
        this.handleScroll = _.throttle(this.scroll, 500);
        window.addEveneListener('scroll', this.handleScroll);
    }
    componentWillUnmount() {
        window.removeEveneListener('scroll', this.handleScroll);
    }
    scroll() {}
}

在组件中绑定事件需要注意应当在组件销毁的时候进行解绑。而由于节流函数返回了一个新的匿名函数，所以为了之后能够有效解绑，不得不将这个匿名函数存起来，以便于之后使用。

但是在有了装饰器之后，我们就不必在每个绑定事件的地方都手动设置 throttle 方法，只需要在 scroll 函数添加一个 throttle 的装饰器就行了。

const throttle = (time) => {
    let prev = new Date();
    return (target, name, descriptor) => {
        const func = descriptor.value;
        if (typeof func === 'function') {
            descriptor.value = function(...args) {
		        const now = new Date();
		        if (now - prev > wait) {
			        fn.apply(this, args);
			        prev = new Date();
		        }
            }
        }
    }
}

使用起来比原来要简洁很多。

class App extends React.Component {
    componentDidMount() {
        window.addEveneListener('scroll', this.scroll);
    }
    componentWillUnmount() {
        window.removeEveneListener('scroll', this.scroll);
    }
    @throttle(50)
    scroll() {}
}

而实现防抖（debounce）函数装饰器和节流函数类似，这里也不再多说。

const debounce = (time) => {
    let timer;
    return (target, name, descriptor) => {
        const func = descriptor.value;
        if (typeof func === 'function') {
            descriptor.value = function(...args) {
                if(timer) clearTimeout(timer)
                timer = setTimeout(()=> {
                    fn.apply(this, args)
                }, wait)
            }
        }
    }
}

如果对节流和防抖函数比较感兴趣，那么可以去阅读一下这篇文章：函数节流与函数防抖

4.3 数据格式验证

通过类属性装饰器来对类的属性进行类型的校验。

const validate = (type) => (target, name) => {
    if (typeof target[name] !== type) {
        throw new Error(`attribute ${name} must be ${type} type`)
    }
}
class Form {
    @validate('string')
    static name = 111 // Error: attribute name must be ${type} type
}

如果你觉得对属性一个个手动去校验太过麻烦，也可以通过编写校验规则，来对整个类进行校验。

const rules = {
    name: 'string',
    password: 'string',
    age: 'number'
}
const validator = rules => targetClass => {
    return new Proxy(targetClass, {
        construct(target, args) {
            const obj = new target(...args);
            for (let [name, type] of Object.entries(rules)) {
                if (typeof obj[name] !== type) {
                    throw new Error(`${name} must be ${type}`)
                }
            }
            return obj;
        }
    })
}

@validator(rules)
class Person {
    name = 'tom'
    password = '123'
    age = '21'
}
const person = new Person();

4.4 core-decorators.js

core-decorators 是一个封装了常用装饰器的 JS 库，它归纳了下面这些装饰器（只列举了部分）。

1. autobind：自动绑定 this，告别箭头函数和 bind
2. readonly：将类属性设置为只读
3. override：检查子类的方法是否正确覆盖了父类的同名方法
4. debounce：防抖函数
5. throttle：节流函数
6. enumerable：让一个类方法变得可枚举
7. nonenumerable：让一个类属性变得不可枚举
8. time：打印函数执行耗时
9. mixin：将多个对象混入类（和我们上面的 mixin 不太一样）

5. 总结

装饰器虽然还属于不稳定的语法，但在很多框架中都已经广泛使用，例如 Angular、Nestjs 等等，和 Java 中的注解用法非常相似。
装饰器在 TypeScript 中结合反射后还有一些更高级的应用，下篇文章会进行深入讲解。

推荐阅读：

1. 装饰器 —— 阮一峰
2. JS 装饰器（Decorator）场景实战
3. 探索JavaScript中的装饰器模式
4. 王者荣耀之「装饰者模式」
   

1. 前言

前几天在知乎看到了一个问题，React 的 Hooks 是否可以改为用类似 vue3 composition api 的方式实现？

关于 React Hooks 和 Vue3 Composition API 的热烈讨论一直都存在，虽然两者本质上都是实现状态逻辑复用，但在实现上却代表了两个社区的不同发展方向。

我想说，小孩子才分好坏，成年人表示我全都要。

2. 你不知道的 Object.defineProperty

那今天我们来讨论一下怎么用 React Hooks 来实现 Vue3 Composition 的效果。

先来看一下我们最终要实现的效果。

看到这个 API 的用法你会联想到什么？没错，很明显这里借用了 Proxy 或者 Object.defineProperty。

在《你不知道的 Proxy：ES6 Proxy 能做哪些有意思的事情？》一文中，我们已经对比过两者的用法了。

其实这里还有一个不为人知的区别，那就是可以通过 Object.defineProperty 给对象添加一个新属性。

const person = {}
Object.defineProperty(person, "name", {
    enumerable: true,
    get() {
        return "sh22n"
    }
})

打印出来的效果是这样的：

这就很有意思了，意味着我们可以把某个对象 A 上所有属性都挂载到对象 B 上，这样我们不必对 A 进行任何监听，即不会污染 A。

const state = { count: 0 }
Object.defineProperty({}, "count", {
    get() {
        return state.count
    }
})

3. React Hooks + Object.defineProperty = ?

如果将上面的代码结合 React Hooks，那会出现什么效果呢？没错，我们的 Hooks 变得更加 reactive 了。

const [state, setState] = useState({ count: 0 })
const proxyState = Object.defineProperty({}, "count", {
    get() {
        return state.count
    },
    set(newVal) {
        setState({ ...state, count: newVal })
    }
})
return (
    <h1 onClick={() => proxyState.count++}>
        { proxyState.count }
    </h1>
)

将这段代码进一步封装，可以得到一个 Custom Hook，也就是我们今天要说的 Composition API。

const ref = (value) => {
    const [state, setState] = useState(value)
    return Object.defineProperty({}, "count", {
        get() {
            return state.count
        },
        set(newVal) {
            setState({ ...state, count: newVal })
        }
    })
}
function Counter() {
    const count = ref({ value: 0 })
    return (
        <h1 onClick={() => count.value++}>
            { count.value }
        </h1>
    )
}

当然，这段代码还存在很多问题，依赖了对象的结构、不支持更深层的 getter/setter 等等，我们接下来就一起来优化一下。

4. 实现 Composition

4.1 递归劫持属性

对于有多个属性的对象来说，我们可以遍历，配合 Object.defineProperties 来劫持它的所有属性。

const descriptors = Object.keys(state).reduce((handles, key) => {
    return {
        ...handles,
        [key]: {
            get() {
                return state[key]
            },
            set(newVal) {
                setState({ ...state, [key]: newVal })
            }
        }
    }
}, {})
Object.defineProperty({}, descriptors)

而对于更深层的对象来说，不仅要做递归，还要考虑 setState 这里应该根据访问路径来设置。
首先，我们来对深层对象做一次递归。

const descriptors = (obj) => {
    return Object.keys(obj).reduce((handles, key) => {
        let value = obj[key];
        // 如果 value 是个对象，那就递归其属性进行 `setter/getter`
        if (Object.prototype.toString.call(obj) === "[object Object]") {
            value = Object.defineProperty({}, descriptors(value));
        }
        return {
            ...handles,
            [key]: {
                get() {
                    return value
                },
                set(newVal) {
                    setState({ ...state, [key]: newVal })
                }
            }
        }
    }, {})
}

如果你仔细观察了这段代码，会发现有个非常致命的问题。那就是在做递归的时候，set(newVal) 里面的代码并不对，state 是个深层对象，不能这么简单地对其外层进行赋值。
这意味着，我们需要将访问这个对象深层属性的一整条路径保存下来，以便于 set 到正确的值，可以用一个数组来收集路径上的 key 值。
这里用使用 lodash 的 set 和 get 来做一下演示。

const descriptors = (obj, path) => {
    return Object.keys(obj).reduce((handles, key) => {
        // 收集当前路径的 key 
        let newPath = [...path, key],
            value = _.get(state, newPath);

        // 如果 value 是个对象，那就递归其属性进行 `setter/getter`
        if (Object.prototype.toString.call(obj) === "[object Object]") {
            value = Object.defineProperty({}, descriptors(value, newPath));
        }
        return {
            ...handles,
            [key]: {
                get() {
                    return value
                },
                set(newVal) {
                    _.set(state, newPath, newVal)
                    setState({ ...state })
                }
            }
        }
    }, {})
}

但是，如果传入的是个数组，这里就会有问题了。因为我们只是对 Object 进行了拦截，没有对 Array 进行处理。

const isArray = arr => Object.prototype.toString.call(arr) === '[object Array]'
const isObject = obj => Object.prototype.toString.call(arr) === '[object Object]'

const descriptors = (obj, path) => {
    return Object.keys(obj).reduce((handles, key) => {
        // 收集当前路径的 key 
        let newPath = [...path, key],
            value = _.get(state, newPath);

        // 如果 value 是个对象，那就递归其属性进行 `setter/getter`
        if (isObject(value)) {
            value = Object.defineProperties({}, descriptors(value, newPath));
        }
        if (isArray(value)) {
            value = Object.defineProperties([], descriptors(value, newPath));
        }
        return {
            ...handles,
            [key]: {
                get() {
                    return value
                },
                set(newVal) {
                    _.set(state, newPath, newVal)
                    setState({ ...state })
                }
            }
        }
    }, {})
}

5. 完整版

这样，我们就实现了一个完整版的 ref，我将代码和示例都放到了 codesandbox 上面：Compostion API

const ref = (value) => {
  if (typeof value !== "object") {
    value = {
      value
    };
  }
  const [state, setState] = useState(value);
  const descriptors = (obj, path) => {
    return Object.keys(obj).reduce((result, key) => {
        let newPath = [...path, key];
        let v = _.get(state, newPath);
        if (isObject(v)) {
                v = Object.defineProperties({}, descriptors(v, newPath));
            } else if (isArray(v)) {
                v = Object.defineProperties([], descriptors(v, newPath));
            }
            
        return {
            ...result,
            [key]: {
                enumerable: true,
                get() {
                    return v;
                },
                set(newVal) {
                    setState(
                        _.set(state, newPath, newVal)
                        setState({ ...state })
                    );
                }
            }
        };
        }, {});
    };
    return Object.defineProperties(isArray(value) ? [] : {}, descriptors(state, []));
};

❤️ 看完三件事

如果你觉得这篇内容对你挺有启发，我想邀请你帮我三个小忙：

1. 点赞，让更多的人也能看到这篇内容（收藏不点赞，都是耍流氓 -_-）
2. 关注公众号「前端小馆」，或者加我个人微信号「testygy」拉你进群，不定期分享原创知识。
3. 也看看其它文章

本文来自工业聚在 React China 论坛的分享。

问答

1. 工业聚大大您好。前一阶段参加了几次面试，有几个公司面试反馈说前端掌握的深度不够，这个问题我感觉很令人费解，但是也是我需要加深的方向。
   所以我想请问工业聚大大，向我们这种毕业1-3年的前端，该怎么做去加强自己在前端领域的深度呢，同时又能保持基本的技术广度呢？感谢您的回答!

   不管是技术深度还是广度，都依赖于一个扎实的技术基础。如果还没有通读过《JavaScript权威指南》、《JavaScript 高级程序设计》、《JavaScript DOM编程艺术》等经典书籍，可以开始啃起来了。

   然后，可以开始实现常见的 UI 和交互效果，比如轮播图，移动端的 swiper，Tab 切换，下拉刷新等等。每一种效果，都有从低到高的完成度。比如。轮播图里，有无小圆点切换，有无左右箭头，是否支持定时轮播，是否可以无限循环地轮播，是否支持移动端 touch 事件等等，都反映了你写的效果的完备性和完成度。不断地提高它们，同时也就打磨了 JS 编程能力。

   其他还有模板引擎（templte engine），lodash/underscore，jquery/zepto，react/vue 等不同类型的库或框架，先不看它们的源码，按照你对其 API 的理解，仿写一个最小可运行版本。再去看它们源码，印证你的实现跟原版实现的差异。

   技术的深度和广度，都是积累而来的，无法一蹴而就。如果没有相对严酷的历练，难以沉淀下来深刻的知识和领悟。

2. 你好，工业聚。我想问下作为一个刚毕业半年的前端开发，有必要系统的去学习css3基础，JavaScript基础吗？意思是每当学习我一些东西，就做好记录，比如我会写博客。但感觉节奏很慢，比如3月打算将css3基础系统学习，一忙就基本把这个计划又推到下个月了，只做到一小部分。
   总结了一下，发现自己确实有点拖延症，而且容易被一些环境左右。我想问下对于初出茅庐的前端，如何克服这些问题。比如如何做一个好的规划，如何不要被一些环境所左右？谢谢。

   你的问题跟二楼的有点类似，可以参考对二楼的回答。

   这里可以再总结一下，我们可以回顾自己现在掌握的知识和技能，可以发现，绝大多数都来自于曾经的严酷训练（如高中彻夜复习、暑假集中培训等）。那是一段当时并不轻松，但回想起来很充实的状态。有人称之为「学习区」，在「学习区」我们不轻松但成长最快。在「舒适区」我们很轻松，但成长较慢；在「恐慌区」，我们无所适从，只想逃离。

   现在让你直接看 react/vue 的源码，可能直接进入了你的「恐慌区」，觉得自己水平很差、人很蠢。我们需要找到自己的「学习区」，每个阶段我们的学习区都是不同的。如果没有打好基础，那么「学习区」会一直停留在基础知识的层面，一进入更高领域，就会感到不适和恐慌。基础知识是每个学习者无法逃避的一个学习阶段，一定要通过某种方式突破它，并且这个方式一定不是轻松的（不是舒适区）。

   「拖延现象」是逃避有难度的事情，沉迷自己舒适区的一种行为表现。在现在信息碎片化和信息娱乐化的时代，让人立刻得到短暂愉悦（如看抖音、刷微博、微信等）的事物太多了。需要鼓起很大的意志，刻意让自己去做有难度的事情，并坚持去做。最后会有显著成长。

   先明确自己有要去改变的意愿，再强迫自己有尝试去改变的行为，并开始对自己的不作为，感到愤怒。从内心形成自趋力，最后形成习惯。初期必定痛苦，习惯之后可以体会到乐趣。

3. 工业聚你好，我想问一下为什么 React 会废弃掉 componentWill* ？他们跟 fiber 和 suspend 有关系吗？谢谢！

   是的，主要跟 suspend 特性有关。

   react suspend 特性的实现机制是，重复执行 render 流程。第一次执行 render 时，fetcher.read 方法里的 promise 如果还没有 resolve，就 throw promise，终止此次渲染。然后进入 componentDidCatch 的阶段，catch 到 promise 后，在 promise.then 时，再次触发渲染流程。

   这个机制要求async-safe，类似于 restful api 里两次 get 请求预期拿到一样的结果，虽然第一次 get 被 abort 了，但不应该影响第二次 get 到的结果。

   上面说的是「重复执行 render 流程」，而非「重复执行 render 方法」，「render 流程」里包含 componentWillMount、componentWillReceiveProps 和 componentWillUpdate 等生命周期，如果在这些生命周期里操作了 component 实例的属性或调用了有副作用的方法，那么两次渲染流程就无法满足「幂等」要求。

   所以，干掉 will*，把 willReceiveProps 挪出到静态方法 getDerivedStateFromProps，可以防止开发者操作 component 实例，增加 async-safe 的安全性。

4. 工业聚你好，我想了解一下，你是如何平衡事业、家庭、个人娱乐、个人能力提升、知识输出这几部分的精力和时间的？（你上次好像提到通过原始积累形成系统以后，可以让后续提升和知识输出的效率大幅提高，但是这个原始积累也是很花时间精力的啊，所以你那时候还是单身？）

   在前端领域我的技术积累，是由我的老婆（当时的女朋友）推动的。我之前对 IT 技术没什么了解，她认为我在这方面骨骼清奇，怂恿我去学习。

   原始积累的方式主要是两个：1）做 web 特效 demo 向她表达爱意；2）在她公司的楼下，等她加班完毕的间隙，看 web 领域的电子书，打下扎实的基础。

   我老婆比我优秀得多，我在平衡事业、家庭、娱乐等方面很弱，全靠她敲打。

5. 您好！我想请问一下，非计算机相关专业自学的前端，现在大四在实习，想工作几年有机会跳槽去大厂，需要系统的学习一些后端的知识吗，比如数据库，算法等等，还有在工作项目中要多积累哪些方面，可以在简历上有亮点

   对前端来说，系统地学习后端知识，在求职阶段不是必要的；但一点都不了解，也不合适。适当了解一些。

   不必等工作几年再去考虑大厂，可以现在就去投，去面试，去考虑。即便面试被刷掉了，你也可以知道自己要满足大厂的要求，应该加强哪些方面。

6. 你好，想请问在工作之外是如何安排时间去学习技术的？
   对你而言，工作内容和个人项目带给你的技术上的成长分别占比多少呢？
   感谢。

   在学习技术上，我是兴趣驱动的。学习技术，对我而言，跟玩撸啊撸，守望先锋等游戏有相似的乐趣，并且更不容易腻，成就感也更强。这是一个很好的状态，我不知道怎么进入了它，我希望后面可以一直保持住这种热情。

   我的成长 80% 发生在工作内容，个人项目只有 20% 的增益。但恰恰是个人项目，使我得到机会去付诸工作实践。所以从重要性来讲，个人项目里我的积累，也很重要。目前可以说是工作和业余的技术学习，对技术成长而言，同等重要。

7. 你好，其实我一开始还想了几个问题去问你，不过转念一想都是 Google 能解决的，就不强问技术或者学习能力方面的了。
   就是闲聊一下，有没有什么技术或者知识对你来说只是 Just for fun 所以才去掌握的。

   这个问题非常好。在进入技术领域之前，我对数学、物理学、哲学、心理学以及演化论都很感兴趣，我认为它们是理解世界的不同维度，缺了任何一个，都缺少了一个重要的、不可替代的视角。

   我对技术的兴趣，也延续了上面的特征。计算机是另一个庞大的、重要的世界的体现，如果不懂计算机及编程，就像一个麻瓜，所见皆如魔法。

   仅仅掌握编程语言，也不足够，还需要对编程语言如何被创造有所了解。这就进入编程语言的设计和实现的领域。除此之外，很多问题，无法手写规则解决，必须通过特殊途径，间接解决。这就进入了人工智能/机器学习的领域。而在很多领域，最后都会触及到数学跟编程的结合，目前最贴近数学的是函数式编程语言，又是一个新领域。

   正是对世界和自我的反思与好奇，不断引领我去了解不同的领域。虽然难以成为每个上述领域的专家，但光是得到一些知识的理解，都足够让我兴奋很久。

   在现代，没有人可以掌握人类创造的所有知识。我们需要根据自身兴趣，对知识做一个优先级的划分。我的划分方式是先去掌握纲领性的知识，它们可能是所有知识的核心部分，可以创造新知识，或者推导出旧知识。数学、物理、哲学、心理学、演化论、计算机编程、编程语言实现、人工智能/机器学习、函数式编程等，都属于我认为的纲领性知识的范畴。

8. 目前公司比较大，大公司的通病就是可能每个人都是螺丝钉，只在自己的岗位上去做事情，但是带来的问题就是自己可能会很长时间只钻一个地方，比如我是前端，可能就一直写页面，用RN，就一直用RN，我希望强化自己的后端或者其它框架，但是却没有办法，时间久了担心自己其它方面会越来越弱，也许某一块会比较熟练，但是毕竟范围有限，请问如何解决这一现状呢？或者说从自身角度出发，如何去改变它呢？

   工作不是技术成长的全部，工作之外，可以有基于兴趣的技术探索和积累。而且，工作内容，其实也有很多可挖掘和拓展的地方。靠外界环境去提供一个开发而广阔的学习，基本上不太可能。也不符合公司用人的专业性要求。内心的自我驱动力更可靠。

9. 你好，请问对于其他的框架，如Vue, Angular, Ember, Backbone等等了解多不多？为何当初选择深入钻研React？你认为对于常用React的程序员来说，学习其他前端框架的时候有什么需要特别注意的吗？

   对 Backbone 和 Vue 的了解较多，Angular 和 Ember 不是很了解。当初选择 React 是恰巧当时它比较火，所以去学习和使用，然后有了更深的理解，开始在工作里使用，就这样上了这个车。

   不管是学习其他框架还是其他语言，我认为，都要以腾空自己的心态去感受；不要刻意去想，这不就是 React 里的 xxx 吗？这不就是 C# 里的函数重载吗？虽然我们第一次在 React 或 C# 里发现了某个语言特性或者框架特性，但并非这个特性的内部机制和用途，就跟我们第一次接触的框架和语言绑定了。

   我们应该去理解脱离框架和语言表象的背后的抽象事物，而不是用这个具体事物去理解另一个具有相似性质的具体事物。用水果去理解苹果和香蕉，而不是用苹果去理解香蕉。

10. 工业聚你好。我是一个什么都接触的二傻搬砖，有以下问题想请教一下：
    我主要想应用一下机器学习，这样学习伊始是否需要一些大学数学基础（全忘了，如果需要还要复习一下），下手建议从传统机器学习算法还是直接上深度学习的框架
    React / Vue / Angular 这类框架已经极大的方便了前端工程师的开发，您觉得未来的前端框架演化会接着朝一个怎么样的方向发展，是否还会有 jQuery -> MVVM 的跳跃式改变。
    想看看您对未来前端职责和后端职责的看法，因为目前有许多项目的后端其实也是由我们「前端」来执行完成的，前后端的界限似乎越来越模糊。
    对于目前业界「知识付费」你有什么看法吗？或者对于现在前端圈造网红的现象有什么看法。您接触过这样经常「知识付费」的人吗？是否会影响正常的工作和知识积累。
    对于「前端门槛低」的说法您有什么看法，前端门槛低到底是一种好现象还是一种泥石流？
    在社招招聘开发时，您更看重学习能力还是之前所做的项目的匹配度。

    1、关于机器学习，我前面有个回答是相关的，可以参考一下。我建议从传统机器学习算法学起，就像卡马克 的做法（虽然不必那么硬核，但手写算法还是有很大帮助）。数学、编程和机器学习建模等，是并驾齐驱，互相增益的关系，在学习过程中，自然而然地会发现需要补充的数学部分，编程部分和建模部分是什么。从数学开始学起，离做出一个东西会隔很远很远，而且，数学是学不完的。不必在手写算法上停留过长的时间，积累了一定的经验和体会之后，应该是时候去玩框架了。目前的资料和教程也越发丰富。比如 Google 的机器学习速成

    2、React、Vue 和 Angular 目前只是在数据和视图的绑定以及状态管理上，提供了一些便利。但在 css/style 布局，UI 动画等方面，还有很大的发展空间，等到 houdini 落地，或许会有一个兼顾布局、动效、数据、视图和状态管理的新范式，FRP 是其中一个方向。另外，js 语言的发展，也可能改善一些写法，如 pipeline operator, partial application ，pattern-matching 等。以及 elm, reasonml 等编译到 js 的语言，和 wasm.js 开启的新的竞争领域的冲击，也在推动前端的发展。jQuery -> MVC| MVVM | Flux 这个转变，只是开始，远未到终点。

    3、前端和后端，本来就是人为划分，是之前或现在的分工需求。随着 Backbend、OPS 、 GUI开发乃至人工智能等技术和工具的发展，分工的模式被改变是意料之内、情理之中。做技术的人，要保持「终身学习」的决心和习惯，去迎接更多的挑战，并从中感到乐趣。

    4、目前的「知识付费」处于一个野蛮生长的萌芽阶段，绝大多数知识，并没有进入付费者的大脑。不过，如果把「知识付费」看成是一个像「密室逃脱」的娱乐来看，去掉知识的神圣感后，其实也算不错的体验。我们愿意让肉体去游乐场付费玩过山车，也可以让大脑在网络上玩「知识体验的过山车」。在现阶段，想要获得有竞争力的长进不能只寄希望于「知识付费」里。

    5、前端门槛低是事实。是好是坏，要看有什么角度或者处于什么情境。门槛低，意味着竞争者多，如果是一个不求进步，只图安稳的人，会感觉到竞争者很多，到处都是想抢饭碗的人。但另一方面，如果是一个对技术有追求，有热情，学习的方法论正确的人，他更容易脱颖而出。

    6、社招时的判断因素很多，对不同工作年限的候选人，衡量的方式也不同。对于初入社会的人，主要看对方的学习能力、学习的方法论、获取知识的媒介以及当前的技术基础等。对于资深的候选人，主要考察对流行框架和编程范式的认知和实践经验，对疑难咋整的处理办法，对团队协作的管理策略，以及对软件开发架构和设计模式的个人体悟。

前言

JavaScript 中的类型转换一直都是让前端开发者最头疼的问题。前阵子，推特上有个人专门发了一张图说 JavaScript 让人不可思议。

除了这个，还有很多经典的、让 JavaScript 开发者摸不着头脑的类型转换，譬如下面这些，你是否知道结果都是多少？

1 + {} === ?
{} + 1 === ?
1 + [] === ?
1 + '2' === ?

本文将带领你从 ECMA 规范开始，去深入理解 JavaScript 中的类型转换，让类型转换不再成为前端开发中的拦路虎。

数据类型

JS 中有六种简单数据类型：undefined、null、boolean、string、number、symbol，以及一种复杂类型：object。
但是 JavaScript 在声明时只有一种类型，只有到运行期间才会确定当前类型。在运行期间，由于 JavaScript 没有对类型做严格限制，导致不同类型之间可以进行运算，这样就需要允许类型之间互相转换。

类型转换

显式类型转换

显式类型转换就是手动地将一种值转换为另一种值。一般来说，显式类型转换也是严格按照上面的表格来进行类型转换的。

常用的显式类型转换方法有 Number、String、Boolean、parseInt、parseFloat、toString 等等。
这里需要注意一下 parseInt，有一道题偶尔会在面试中遇到。

问：为什么 [1, 2, 3].map(parseInt) 返回 [1,NaN,NaN]?
答：parseInt函数的第二个参数表示要解析的数字的基数。该值介于 2 ~ 36 之间。

如果省略该参数或其值为 0，则数字将以 10 为基础来解析。如果它以 “0x” 或 “0X” 开头，将以 16 为基数。

如果该参数小于 2 或者大于 36，则 parseInt() 将返回 NaN。
一般来说，类型转换主要是基本类型转基本类型、复杂类型转基本类型两种。
转换的目标类型主要分为以下几种：

1. 转换为 string
2. 转换为 number
3. 转换为 boolean

我参考了 ECMA-262 的官方文档来总结一下这几种类型转换。ECMA 文档链接：ECMA-262

ToNumber

其他类型转换到 number 类型的规则见下方表格：

1. 如果字符串中只包含数字，那么就转换为对应的数字。
2. 如果字符串中只包含十六进制格式，那么就转换为对应的十进制数字。
3. 如果字符串为空，那么转换为0。
4. 如果字符串包含上述之外的字符，那么转换为 NaN。

使用+可以将其他类型转为 number 类型，我们用下面的例子来验证一下。

+undefined // NaN
+null // 0
+true // 1
+false // 0
+'111' // 111
+'0x100F' // 4111
+'' // 0
'b' + 'a' + + 'a' + 'a' // 'baNaNa'
+Symbol() // Uncaught TypeError: Cannot convert a Symbol value to a number

ToBoolean

Boolean(undefined) // false
Boolean(1) // true
Boolean(0) // false
Boolean(NaN) // false
Boolean(Symbol()) // true
Boolean({}) // true

ToString

`${undefined}` // 'undefined'
`${true}` // 'true'
`${false}` // 'false'
`${11}` // '11'
`${Symbol()}` // Cannot convert a Symbol value to a string
`${{}}`

隐式类型转换

隐式类型转换一般是在涉及到运算符的时候才会出现的情况，比如我们将两个变量相加，或者比较两个变量是否相等。
隐式类型转换其实在我们上面的例子中已经有所体现。对于对象转原始类型的转换，也会遵守 ToPrimitive 的规则，下面会进行细说。

从ES规范来看类型转换

ToPrimitive

在对象转原始类型的时候，一般会调用内置的 ToPrimitive 方法，而 ToPrimitive 方法则会调用 OrdinaryToPrimitive 方法，我们可以看一下 ECMA 的官方文档。

我来翻译一下这段话。

ToPrimitive 方法接受两个参数，一个是输入的值 input，一个是期望转换的类型 PreferredType。

1. 如果没有传入 PreferredType 参数，让 hint 等于"default"
2. 如果 PreferredType 是 hint String，让 hint 等于"string"
3. 如果 PreferredType 是 hint Number，让 hint 等于"number"
4. 让 exoticToPrim 等于 GetMethod(input, @@toPrimitive)，意思就是获取参数 input 的 @@toPrimitive 方法
5. 如果 exoticToPrim 不是 Undefined，那么就让 result 等于 Call(exoticToPrim, input, « hint »)，意思就是执行 exoticToPrim(hint)，如果执行后的结果 result 是原始数据类型，返回 result，否则就抛出类型错误的异常
6. 如果 hint 是"default"，让 hint 等于"number"
7. 返回 OrdinaryToPrimitive(input, hint) 抽象操作的结果

OrdinaryToPrimitive

而 OrdinaryToPrimitive 方法也接受两个参数，一个是输入的值O，一个也是期望转换的类型 hint。

1. 如果输入的值是个对象
2. 如果 hint 是个字符串并且值为'string'或者'number'
3. 如果 hint 是'string'，那么就将 methodNames 设置为 toString、valueOf
4. 如果 hint 是'number'，那么就将 methodNames 设置为 valueOf、toString
5. 遍历 methodNames 拿到当前循环中的值 name，将 method 设置为 O[name]（即拿到 valueOf 和 toString 两个方法）
6. 如果 method 可以被调用，那么就让 result 等于 method 执行后的结果，如果 result 不是对象就返回 result，否则就抛出一个类型错误的报错。

ToPrimitive 的代码实现

如果只用文字来描述，你肯定会觉得过于晦涩难懂，所以这里我就自己用代码来实现这两个方法帮助你的理解。

// 获取类型
const getType = (obj) => {
    return Object.prototype.toString.call(obj).slice(8,-1);
}
// 是否为原始类型
const isPrimitive = (obj) => {
    const types = ['String','Undefined','Null','Boolean','Number'];
      return types.indexOf(getType(obj)) !== -1;
}
const ToPrimitive = (input, preferredType) => {
    // 如果input是原始类型，那么不需要转换，直接返回
    if (isPrimitive(input)) {
        return input;
    }
    let hint = '', 
        exoticToPrim = null,
        methodNames = [];
    // 当没有提供可选参数preferredType的时候，hint会默认为"default"；
    if (!preferredType) {
        hint = 'default'
    } else if (preferredType === 'string') {
        hint = 'string'
    } else if (preferredType === 'number') {
        hint = 'number'
    }
    exoticToPrim = input.@@toPrimitive;
    // 如果有toPrimitive方法
    if (exoticToPrim) {
        // 如果exoticToPrim执行后返回的是原始类型
        if (typeof (result = exoticToPrim.call(O, hint)) !== 'object') {
            return result;
        // 如果exoticToPrim执行后返回的是object类型
        } else {
            throw new TypeError('TypeError exception')
        }
    }
    // 这里给了默认hint值为number，Symbol和Date通过定义@@toPrimitive方法来修改默认值
    if (hint === 'default') {
        hint = 'number'
    }
    return OrdinaryToPrimitive(input, hint)
}
const OrdinaryToPrimitive = (O, hint) => {
    let methodNames = null,
        result = null;
    if (typeof O !== 'object') {
        return;
    }
    // 这里决定了先调用toString还是valueOf
    if (hint === 'string') {
        methodNames = [input.toString, input.valueOf]
    } else {
        methodNames = [input.valueOf, input.toString]
    }
    for (let name in methodNames) {
        if (O[name]) {
            result = O[name]()
            if (typeof result !== 'object') {
                return result
            }
        }
    }
    throw new TypeError('TypeError exception')
}

总结一下，在进行类型转换的时候，一般是通过 ToPrimitive 方法将引用类型转为原始类型。如果引用类型上有 @@toPrimitive 方法，就调用 @@toPrimitive 方法，执行后的返回值为原始类型就直接返回，如果依然是对象，那么就抛出报错。

如果对象上没有 toPrimitive 方法，那么就根据转换的目标类型来判断先调用 toString 还是 valueOf 方法，如果执行这两个方法后得到了原始类型的值，那么就返回。否则，将会抛出错误。

Symbol.toPrimitive

在 ES6 之后提供了 Symbol.toPrimitive 方法，该方法在类型转换的时候优先级最高。

const obj = {
  toString() {
    return '1111'
  },
  valueOf() {
    return 222
  },
  [Symbol.toPrimitive]() {
    return 666
  }
}
const num = 1 + obj; // 667
const str = '1' + obj; // '1666'

例子

也许上面关于 ToPrimitive 的代码讲解你还是会觉得晦涩难懂，那我接下来就举几个例子来说明对象的类型转换。

var a = 1, 
    b = '2';
var c = a + b; // '12'

也许你会好奇，为什么不是将后面的 b 转换为 number 类型，最后得到3？
我们还是要先看文档对加号的定义。

首先会分别执行两个值的 toPrimitive 方法，因为 a 和 b 都是原始类型，所以还是得到了1和'2'。
从图上看到如果转换后的两个值的 Type 有一个是 String 类型，那么就将两个值经过 toString 转换后串起来。因此最后得到了'12'，而不是3。

我们还可以再看一个例子。

var a = 'hello ', b = {};
var c = a + b; // "hello [object Object]"

这里还会分别执行两个值的 toPrimitive 方法，a 还是得到了'hello '，而b由于没有指定preferredType，所以会默认被转为 number 类型，先调用 valueOf，但 valueOf 还是返回了一个空对象，不是原始类型，所以再调用 toString，得到了 '[object Object]'，最后将两者连接起来就成了 "hello [object Object]"。
如果我们想返回 'hello world'，那该怎么改呢？只需要修改 b 的 valueOf 方法就好了。

b.valueOf = function() {
    return 'world'
}
var c = a + b; // 'hello world'

也许你在面试题中看到过这个例子。

var a = [], b = [];
var c = a + b; // ''

这里为什么 c 最后是''呢？因为 a 和 b 在执行 valueOf 之后，得到的依然是个 [] ，这并非原始类型，因此会继续执行 toString，最后得到''，两个''相加又得到了''。
我们再看一个指定了 preferredType 的例子。

var a = [1, 2, 3], b = {
    [a]: 111
}

由于 a 是作为了 b 的键值，所以 preferredType 为 string，这时会调用 a.toString 方法，最后得到了'1,2,3'

总结

类型转换一直是学 JS 的时候很难搞明白的一个概念，因为转换规则比较复杂，经常让人觉得莫名其妙。
但是如果从 ECMA 的规范去理解这些转换规则的原理，那么就会很容易知道为什么最后会得到那些结果。

浅谈react diff实现

这是一篇硬核文，因此不会用生动幽默的语言来讲述，这篇文章大概更像是自己心血来潮的总结吧哈哈哈哈。
有很多文章讲过 react 的 diff 算法，但要么是晦涩难懂的源码分析，让人很难读进去，要么就是流于表面的简单讲解，实际上大家看完后还是一头雾水，因此我将 react-lite（基于 react v15） 中的 diff 算法实现稍微整理了一下，希望能够帮助大家解惑。
对于 react diff，我们已知的有两点，一个是会通过 key 来做比较，另一个是 react 默认是同级节点做diff，不会考虑到跨层级节点的 diff（事实是前端开发中很少有DOM节点跨层级移动的）。

递归更新

首先，抛给我们一个问题，那就是 react 怎么对那么深层次的 DOM 做的 diff？实际上 react 是对 DOM 进行递归来做的，遍历所有子节点，对子节点再做递归，这一过程类似深度优先遍历。

// 超简单代码实现
const updateVNode = (vnode, node) => {
    updateVChildren(vnode, node)
}
const updateVChildren = (vnode, node) => {
    for (let i = 0; i < node.children.length; i++) {
        updateVNode(vnode.children[i], node.children[i])
    }
}

因此，我们这里以其中一层节点来讲解diff是如何做到更新的。

状态收集

假设我们的 react 组件渲染成功后，在浏览器中显示的真实 DOM 节点是A、B、C、D，我们更新后的虚拟DOM是B、A、E、D。
那我们这里需要做的操作就是，将原来 DOM 中已经存在的A、B、D进行更新，将原来 DOM 中原本存在，而现在不存在的C移除掉，再创建新的E节点。
这样一来，问题就简化了很多，我们只需要收集到需要 create、remove和update 的节点信息就行了。

// oldDoms是真实DOM，newDoms是最新的虚拟DOM
const oldDoms = [A, B, C, D],
    newDoms = [B, A, E, D],
    updates = [],
    removes = [],
    creates = [];
// 进行两层遍历，获取到哪些节点需要更新，哪些节点需要移除。
for (let i = 0; i < oldDoms.length; i++) {
    const oldDom = oldDoms[i]
    let shouldRemove = true
    for (let j = 0; j < newDoms.length; j++) {
        const newDom = newDoms[j];
        if (
            oldDom.key === newDom.key &&
            oldDom.type === newDom.type
        ) {
            updates[j] = {
                index: j,
                node: oldDom,
                parentNode: parentNode // 这里真实DOM的父节点
            }
            shouldRemove = false
        }
    }
    if (shouldRemove) {
        removes.push({
            node: oldDom
        })
    }
}
// 从虚拟 DOM 节点来取出不要更新的节点，这就是需要新创建的节点。
for (let j = 0; j < newDoms.length; j++) {
    if (!updates[j]) {
        creates.push({
            index: j,
            vnode: newDoms[j],
            parentNode: parentNode // 这里真实DOM的父节点
        })
    }
}

这样，我们便拿到了想要的状态信息。

diff

在得到需要 create、update 和 remove 的节点后，我们这时就可以开始进行渲染了。
node | 状态 | index
:-: | :-: | :-: | :-: | :-:
A | update | 1
B | update| 0
C | remove
D | update | 3
E | create | 2

首先，我们遍历所有需要 remove 的节点，将其从真实DOM中 remove 掉。因此这里需要 remove 掉C节点，最后渲染结果是A、B、D。

const remove = (removes) => {
    removes.forEach(remove => {
        const node = remove.node
        node.parentNode.removeChild(node)
    })
}

其次，我们再遍历需要更新的节点，将其插入到对应的位置中。所以这里最后渲染结果是B、A、D。

const update = (updates) => {
    updates.forEach(update => {
        const index = update.index,
            parentNode = update.parentNode,
            node = update.node,
            curNode = parentNode.children[index];
        if (curNode !== node) {
            parentNode.insertBefore(node, curNode)
        }
    })
}

最后一步，我们需要创建新的 DOM 节点，并插入到正确的位置中，最后渲染结果为B、A、E、D。

const create = (creates) => {
    creates.forEach(create => {
        const index = create.index,
            parentNode = create.parentNode,
            vnode = create.vnode,
            curNode = parentNode.children[index],
            node = createNode(vnode); // 创建DOM节点
        parentNode.insertBefore(node, curNode)
    })
}

虽然这篇文章写的比较简单，但是一个完整的diff流程就是这样了，可以加深对react的一些理解。当然了，还有一些对 DOM 节点属性之类的比较，这里不做讲解。

react作为现今最火热的前端框架，很多项目都采用了react构建界面，但是react自身也有许多不足，比如状态管理和组件通信等等，随着项目越来越大，只靠react很难满足需求，所以很多状态管理库由此诞生。

全局state

如果是比较小的个人项目，完全可以不使用任何状态库，可以在容器（顶层）组件里面使用一个类似redux store的大state，将这个state通过props和context传给子组件，可以将setState方法从容器组件传下去，或者将子组件的修改state方法放到容器组件中，这样就可以轻松实现状态管理，但是会造成容器组件过于臃肿。

redux

redux是我们公司老项目中最常用的状态库，redux遵守dispatch -> action -> reducer -> store -> view的一套操作流程，好处是具有时间回溯，这在错误调试的时候非常适用。数据流动清晰，组件之间通信也更加方便，缺点就是需要在多个文件里面写很多action和reducer，在小项目中就会得不偿失，但是在大型项目中有利于以后维护。

relite

relite是我们部门的工业聚大神写的一个类redux库，总体**和redux一致，区别只是在于写法上的不同，relite中剔除了reducer的概念，将action和reducer合一，以原来的action.type来命名reducer函数，每个函数最终都会返回整个store，这样无需写一串长长的switch case语句，但也带来了一系列问题，比如由于返回整个store，很难配合PureComponent做性能优化。

mobx

mobx和redux走了完全不同的一条路，mobx更偏向vue等响应式库，通过getter、setter（Proxy）来实现对数据的监听，而mobx-react会提供observer方法来对组件依赖的响应式数据进行收集，这样带来的好处就是可以做到更细粒度的控制组件渲染，可以带来更高效的性能，能够做到只渲染子组件而不渲染父组件，甚至可以用组件内部可观察的数据来代替state，避免由于state的‘异步’特性导致的问题，这些在react和redux里面是无法做到的。

rematch

由于redux写法过于繁琐，所以出现了很多对redux重新思考后而设计的库，其中rematch是比较优秀的一个。
我们都知道redux的写法很繁琐，比如createStore的时候，为什么要写成createStore(reducers, initialStore, applyMiddleware(thunk, logger))这种形式，写成可配置的不好吗？const store = {middleware: [thunk, logger], initialStore: {}, reducers: {count}}这种不是更好？为什么reducer里面还要用switch这么繁琐的条件语句？表驱动不是更好？
基于这种考虑，rematch应然而生。rematch将reducer和action合并到一个对象中，提供了effects来承载异步操作（请求接口等），这样的好处就是用户触发的action实际上就是reducer，这和relite的**基本一致。

如果是小型项目，也许你不需要使用状态管理库，如果实在操作不好，那么可以考虑一下relite，如果是中大型项目，可以考虑使用mobx，如果是业务很复杂的项目，那么建议使用redux和rematch。

前言

JavaScript 在设计之初，是一门具有函数式、面向对象（ OOP ）等风格的多范式语言。
虽然 JavaScript 中到处都是“对象”，但如果想要 JavaScript 中使用类，在 ES5 之前需要使用构造函数和原型（ prototype ）来模拟类，而涉及到继承的时候，实现方式之多更是让人眼花缭乱。
因此，在 ES6 之后，JavaScript 增加了 class 和 extends 关键字，这让JavaScript更加接近传统的面向对象语言，也方便了开发。

本文比较基础，如果对知识点已经比较了解，可以跳过本文。如果觉得不够了解，那么大家可以来一起复习一下。
本文涉及到对象、构造函数、原型（ prototype ）等知识，如果有不懂的知识点，建议先去熟悉《JavaScript高级程序设计》第六章相关概念后再来阅读。

1. 类

什么是类呢？这里引用一下维基百科的解释：

类（英语：class）在面向对象编程中是一种面向对象计算机编程语言的构造，是创建对象的蓝图，描述了所创建的对象共同的属性和方法。

类是对现实生活中一类具有共同特征的事物的抽象，像老鼠、猫、人类等都可以作为类。但具体的个体就是对象，比如一只叫汤姆的猫，一只叫杰瑞的老鼠。

在 JavaScript 中每个对象都可以都是基于引用类型创建的，这个引用类型可以是原生类型（ Date、String、Boolean 等），也可以是自定义的类型。因此，类也可以被理解为是描述数据和行为的一种复杂类型。

1.1 ES5 中的类

在开始之前，我们先基于上述的描述来实现一个简单的类。
由于类是一种自定义的复杂类型，封装了一类事物的共同特性，而对象只是类返回的一个实例，那么我们完全可以考虑使用函数来创建，最后返回一个对象。
以下面这个人的类为例：

function person(name, age) {
    return {
        name,
        age,
        say() {
            console.log('my name is ', name);
        }
    }
}
person('tom', 23); // { name: 'tom', age: 23, say: f }
person('jerry', 24); // { name: 'jerry', age: 24, say: f }

注意：这段代码充分体现了，在 JavaScript 中到处都是“对象”，只要使用对象字面量就能轻松创建一个对象。

但是这个类的实现方式也有一定问题，比如没有办法设置原型，这样也就无法实现继承。
因此，在 JavaScript 中，一般使用具有 this 的构造函数和 new 操作符来模拟类和对象，这样也是更符合传统面向对象语言开发者直觉的设计。

function Person(name, age) {
    this.name = name;
    this.age = age;
}
Person.prototype.say = function() {
    console.log('my name is ', name);
}
const tom = new Person('tom', 23);
const jerry = new Person('jerry', 24);

当然，你也许会困惑，当使用 new 的时候，它到底做了什么呢？
其实 new 操作符做的事情很简单，大致就是以下几步：

1. 创建一个空对象 obj
2. 执行构造函数，将 this 指向 obj
3. 设置 obj 的 [[Prototype]] 指针指向构造函数的原型 prototype
4. 返回这个对象

按照上面这四步，可以自己手动实现一个 new 操作符。

function myNew() {
    const Constructor = arguments[0],
        args = [...arguments].slice(1), // arguments是类数组，因此需要转换为数组才能使用slice方法
        obj = {};
        
    Constructor.apply(obj, args);
    // 设置[[Prototype]]指针（不推荐）
    obj.__proto__ = Constructor.prototype;
    // 设置[[prototype]]指针（推荐）
    Object.setPrototypeOf(obj, Constructor.prototype);
    return obj;
}