🍧 代号马蹄铁

veedrin


上一章我们了解了`co`与Generator结合的异步编程解决方案。

我知道你想说什么，写一个异步调用还得引入一个npm包(虽然是大神TJ写的包)。

> 妈卖批的npm！

当然是不存在的。如果一个特性足够重要，社区的呼声足够高，它就一定会被纳入标准的。马上我们要介绍的就是血统纯正的异步编程家族终极继承人——爱新觉罗·async。

```javascript
import co from 'co';

function fetchByName(name) {
    const url = `https://api.github.com/users/${name}/repos`;
    return fetch(url).then(res => res.json());
}

co(function *gen() {
    const value1 = yield fetchByName('veedrin');
    console.log(value1);
    const value2 = yield fetchByName('tj');
    console.log(value2);
});
```

```javascript
function fetchByName(name) {
    const url = `https://api.github.com/users/${name}/repos`;
    return fetch(url).then(res => res.json());
}

async function fetchData() {
    const value1 = await fetchByName('veedrin');
    console.log(value1);
    const value2 = await fetchByName('tj');
    console.log(value2);
}

fetchData();
```

看看这无缝升级的体验，啧啧。

## 灵活

别被新的关键字吓到了，它其实非常灵活。

```javascript
async function noop() {
    console.log('Easy, nothing happened.');
}
```

这家伙能执行吗？当然能，老伙计还是你的老伙计。

```javascript
async function noop() {
    const msg = await 'Easy, nothing happened.';
    console.log(msg);
}
```

同样别慌，还是预期的表现。

只有当`await`关键字后面是一个Promise的时候，它才会显现它异步控制的威力，其余时候人畜无害。

```javascript
function fetchByName(name) {
    const url = `https://api.github.com/users/${name}/repos`;
    return fetch(url).then(res => res.json());
}

async function fetchData() {
    const name = await 'veedrin';
    const repos = await fetchByName(name);
    console.log(repos);
}
```

虽然说`await`关键字后面跟Promise或者非Promise都可以处理，但对它们的处理方式是不一样的。非Promise表达式直接返回它的值就是了，而Promise表达式则会等待它的状态从`pending`变为`fulfilled`，然后返回resolve的参数。它隐式的做了一下处理。

注意看，`fetchByName('veedrin')`按道理返回的是一个Promise实例，但是我们得到的`repos`值却是一个数组，这里就是`await`关键字隐式处理的地方。

另外需要注意什么呢？`await`关键字只能定义在async函数里面。

```javascript
const then = Date.now();

function sleep(duration) {
    return new Promise((resolve, reject) => {
        const id = setTimeout(() => {
            resolve(Date.now() - then);
            clearTimeout(id);
        }, duration * 1000);
    });
}

async function work() {
    [1, 2, 3].forEach(v => {
        const rest = await sleep(3);
        console.log(rest);
        return '睡醒了';
    });
}

work();

// Uncaught SyntaxError: await is only valid in async function
```

行吧，那我们把它弄到一个作用域里去。

```javascript
import sleep from './sleep';

function work() {
    [1, 2, 3].forEach(async v => {
        const rest = await sleep(3);
        console.log(rest);
    });
    return '睡醒了';
}

work();
```

不好意思，`return '睡醒了'`没等异步操作完就执行了，这应该也不是你要的效果吧。

所以这种情况，只能用for循环来代替，async和await就能长相厮守了。

```javascript
import sleep from './sleep';

async function work() {
    const things = [1, 2, 3];
    for (let thing of things) {
        const rest = await sleep(3);
        console.log(rest);
    }
    return '睡醒了';
}

work();
```

## 返回Promise实例

有人说async是Generator的语法糖。

naive，朋友们。

async可不止一颗糖哦。它是Generator、co、Promise三者的封装。如果说Generator只是一个状态机的话，那async天生就是为异步而生的。

```javascript
import sleep from './sleep';

async function work() {
    const needRest = await sleep(6);
    const anotherRest = await sleep(3);
    console.log(needRest);
    console.log(anotherRest);
    return '睡醒了';
}

work().then(res => console.log('🙂', res), res => console.error('😡', res));
```

因为async函数返回一个Promise实例，那它本身return的值跑哪去了呢？它成了返回的Promise实例resolve时传递的参数。也就是说`return '睡醒了'`在内部会转成`resolve('睡醒了')`。

我可以保证，返回的是一个真正的Promise实例，所以其他特性向Promise看齐就好了。

## 并发

也许你发现了，上一节的例子大概要等9秒多才能最终结束执行。可是两个`sleep`之间并没有依赖关系，你跟我说说我凭什么要等9秒多？

之前跟老子说要异步流程控制是不是！现在又跟老子说要并发是不是！

我…满足你。

```javascript
import sleep from './sleep';

async function work() {
    const needRest = await Promise.all([sleep(6), sleep(3)]);
    console.log(needRest);
    return '睡醒了';
}

work().then(res => console.log('🙂', res), res => console.error('😡', res));
```

```javascript
import sleep from './sleep';

async function work() {
    const onePromise = sleep(6);
    const anotherPromise = sleep(3);
    const needRest = await onePromise;
    const anotherRest = await anotherPromise;
    console.log(needRest);
    console.log(anotherRest);
    return '睡醒了';
}

work().then(res => console.log('🙂', res), res => console.error('😡', res));
```

办法也是有的，还不止一种。手段都差不多，就是把`await`往后挪，这样既能搂的住，又能实现并发。

## 大总结

关于异步的知识大体上可以分成两大块：异步机制与异步编程。

异步机制的精髓就是事件循环。

通过控制权反转(从事件通知主线程，到主线程去轮询事件)，完美的解决了一个线程忙不过来的问题。

异步编程经历了从`回调`到`Promise`到`async`的伟大探索。异步编程的本质就是用尽可能接近同步的语法去处理异步机制。

`async`目前来看是一种比较完美的同步化异步编程的解决方案。

但其实`async`是深度集成`Promise`的，可以说`Promise`是`async`的底层依赖。不仅如此，很多API，诸如`fetch`也是将`Promise`作为底层依赖的。

所以说一千道一万，异步编程的底色是`Promise`。

而`Promise`是通过什么方式来异步编程的呢？通过`then`函数，`then`函数又是通过回调来解决的。

所以呀，回调才是刻在异步编程基因里的东西。你大爷还是你大爷！

回调换一种说法也叫事件。

这下你理解了为什么说`JavaScript是事件驱动的`吧？


Async 专题 04 —— 也许是终极异步解决方案


Generator简单讲就是一个状态机。但它和Promise不一样，它可以维持无限个状态，并且提出它的初衷并不是为了解决异步编程的某些问题。

一个线程一次只能做一件任务，并且任务与任务之间不能间断。而Generator开了挂，它可以暂停手头的任务，先干别的，然后在恰当的时机手动切换回来。

这是一种纤程或者协程的概念，相比线程切换更加轻量化的切换方式。

## Iterator

在讲Generator之前，我们要先和`Iterator`遍历器打个照面。

`Iterator`对象是一个指针对象，它是一种类似于单向链表的数据结构。JavaScript通过`Iterator`对象来统一数组和类数组的遍历方式。

```javascript
const arr = [1, 2, 3];
const iteratorConstructor = arr[Symbol.iterator];
console.log(iteratorConstructor);

// ƒ values() { [native code] }
```

```javascript
const obj = { a: 1, b: 2, c: 3 };
const iteratorConstructor = obj[Symbol.iterator];
console.log(iteratorConstructor);

// undefined
```

```javascript
const set = new Set([1, 2, 3]);
const iteratorConstructor = set[Symbol.iterator];
console.log(iteratorConstructor);

// ƒ values() { [native code] }
```

我们已经见到了`Iterator`对象的构造器，它藏在`Symbol.iterator`下面。接下来我们生成一个`Iterator`对象来了解它的工作方式吧。

```javascript
const arr = [1, 2, 3];
const it = arr[Symbol.iterator]();

console.log(it.next()); // { value: 1, done: false }
console.log(it.next()); // { value: 2, done: false }
console.log(it.next()); // { value: 3, done: false }
console.log(it.next()); // { value: undefined, done: true }
console.log(it.next()); // { value: undefined, done: true }
```

既然它是一个指针对象，调用`next()`的意思就是把指针往后挪一位。挪到最后一位，再往后挪，它就会一直重复`我已经到头了，只能给你一个空值`。

## Generator

Generator是一个生成器，它生成的到底是什么呢？

对咯，他生成的就是一个`Iterator`对象。

```javascript
function *gen() {
    yield 1;
    yield 2;
    return 3;
}

const it = gen();

console.log(it.next()); // { value: 1, done: false }
console.log(it.next()); // { value: 2, done: false }
console.log(it.next()); // { value: 3, done: false }
console.log(it.next()); // { value: undefined, done: true }
console.log(it.next()); // { value: undefined, done: true }
```

Generator有什么意义呢？普通函数的执行会形成一个调用栈，入栈和出栈是一口气完成的。而Generator必须得手动调用`next()`才能往下执行，相当于把执行的控制权从引擎交给了开发者。

所以Generator解决的是流程控制的问题。

它可以在执行过程暂时中断，先执行别的程序，但是它的执行上下文并没有销毁，仍然可以在需要的时候切换回来，继续往下执行。

最重要的优势在于，它看起来是同步的语法，但是却可以异步执行。

## yield

对于一个Generator函数来说，什么时候该暂停呢？就是在碰到`yield`关键字的时候。

```javascript
function *gen() {
    console.log('a');
    yield 13 * 15;
    console.log('b');
    yield 15 - 13;
    console.log('c');
    return 3;
}

const it = gen();
```

看上面的例子，第一次调用`it.next()`的时候，碰到了第一个`yield`关键字，然后开始计算`yield`后面表达式的值，然后这个值就成了`it.next()`返回值中`value`的值，然后停在这。这一步会打印`a`，但不会打印`b`。

以此类推。`return`的值作为最后一个状态传递出去，然后返回值的`done`属性就变成`true`，一旦它变成`true`，之后继续执行的返回值都是没有意义的。

这里面有一个状态传递的过程。`yield`把它暂停之前获得的状态传递给执行器。

那么有没有可能执行器传递状态给状态机内部呢？

```javascript
function *gen() {
    const a = yield 1;
    console.log(a);
    const b = yield 2;
    console.log(b);
    return 3;
}

const it = gen();
```

当然是可以的。

默认情况下，第二次执行的时候变量`a`的打印结果是`undefined`，因为`yield`关键字就没有返回值。

但是如果给`next()`传递参数，这个参数就会作为上一个`yield`的返回值。

```javascript
it.next('biu');
```

别急，第一次执行没有所谓的上一个`yield`，所以这个参数是没有意义的。

```javascript
it.next('piu');

// 打印 piu。这个 piu 是 console.log(a) 打印出来的。
```

第二次执行就不同了。`a`变量接收到了`next()`传递进去的参数。

这有什么用？如果能在执行过程中给状态机传值，我们就可以改变状态机的执行条件。你可以发现，Generator是可以实现值的双向传递的。

为什么要作为上一个`yield`的返回值？你想啊，作为上一个`yield`的返回值，才能改变当前代码的执行条件，这样才有价值不是嘛。这地方有点绕，仔细想一想。

## 自动执行

好吧，既然引擎把Generator的控制权交给了开发者，那我们就要探索出一种方法，让Generator的遍历器对象可以自动执行。

```javascript
function* gen() {
    yield 1;
    yield 2;
    return 3;
}

function run(gen) {
    const it = gen();
    let state = { done: false };
    while (!state.done) {
        state = it.next();
        console.log(state);
    }
}

run(gen);
```

不错，竟然这么简单。

但想想我们是来干什么的，我们是来探讨JavaScript异步的呀。这个简陋的`run`函数能够执行异步操作吗？

```javascript
function fetchByName(name) {
    const url = `https://api.github.com/users/${name}/repos`;
    fetch(url).then(res => res.json()).then(res => console.log(res));
}

function *gen() {
    yield fetchByName('veedrin');
    yield fetchByName('tj');
}

function run(gen) {
    const it = gen();
    let state = { done: false };
    while (!state.done) {
        state = it.next();
    }
}

run(gen);
```

事实证明，Generator会把`fetchByName`当做一个同步函数来执行，没等请求触发回调，它已经将指针指向了下一个`yield`。我们的目的是让上一个异步任务完成以后才开始下一个异步任务，显然这种方式做不到。

我们已经让Generator自动化了，但是在面对异步任务的时候，交还控制权的时机依然不对。

什么才是正确的时机呢？

## 在回调中交还控制权

哪个时间点表明某个异步任务已经完成？当然是在回调中咯。

我们来拆解一下思路。

- 首先我们要把异步任务的其他参数和回调参数拆分开来，因为我们需要单独在回调中扣一下扳机。
- 然后`yield asyncTask()`的返回值得是一个函数，它接受异步任务的回调作为参数。因为Generator只有`yield`的返回值是暴露在外面的，方便我们控制。
- 最后在回调中移动指针。

```javascript
function thunkify(fn) {
    return (...args) => {
        return (done) => {
            args.push(done);
            fn(...args);
        }
    }
}
```

这就是把异步任务的其他参数和回调参数拆分开来的法宝。是不是很简单？它通过两层闭包将原过程变成三次函数调用，第一次传入原函数，第二次传入回调之前的参数，第三次传入回调，并在最里一层闭包中又把参数整合起来传入原函数。

是的，这就是大名鼎鼎的`thunkify`。

以下是暖男版。

```javascript
function thunkify(fn) {
    return (...args) => {
        return (done) => {
            let called = false;
            args.push((...innerArgs) => {
                if (called) return;
                called = true;
                done(...innerArgs);
            });
            try {
                fn(...args);
            } catch (err) {
                done(err);
            }
        }
    }
}
```

宝刀已经有了，咱们去屠龙吧。

```javascript
const fs = require('fs');
const thunkify = require('./thunkify');

const readFileThunk = thunkify(fs.readFile);

function *gen() {
    const valueA = yield readFileThunk('/Users/veedrin/a.md');
    console.log('a.md 的内容是：\n', valueA.toString());
    const valueB = yield readFileThunk('/Users/veedrin/b.md');
    console.log('b.md 的内容是：\n', valueB.toString());
}

function run(gen) {
    const it = gen();
    const state1 = it.next();
    state1.value((err, data) => {
        if (err) throw err;
        const state2 = it.next(data);
        state2.value((err, data) => {
            if (err) throw err;
            it.next(data);
        });
    });
}

run(gen);
```

卧槽，老夫宝刀都提起来了，你让我切豆腐？

这他妈不就是把回调嵌套提到外面来了么！我为啥还要用Generator，感觉默认的回调嵌套挺好的呀，有一种黑洞般的简洁和性感...

别急，这只是Thunk解决方案的PPT版本，接下来咱们真的要造车并开车了哟，此处@贾跃亭。

```javascript
const fs = require('fs');
const thunkify = require('./thunkify');

const readFileThunk = thunkify(fs.readFile);

function *gen() {
    const valueA = yield readFileThunk('/Users/veedrin/a.md');
    console.log('a.md 的内容是：\n', valueA.toString());
    const valueB = yield readFileThunk('/Users/veedrin/b.md');
    console.log('b.md 的内容是：\n', valueB.toString());
}

function run(gen) {
    const it = gen();
    function next(err, data) {
        const state = it.next(data);
        if (state.done) return;
        state.value(next);
    }
    next();
}

run(gen);
```

我们完全可以把回调函数抽象出来，每移动一次指针就递归一次，然后在回调函数内部加一个停止递归的逻辑，一个通用版的run函数就写好啦。上例中的`next()`其实就是`callback()`呢。

## 在Promise中交还控制权

处理异步操作除了回调之外，我们还有异步容器Promise。

和在回调中交还控制权差不多，于Promise中，我们在then函数的函数参数中扣动扳机。

我们来看看威震海内的`co`。

```javascript
function co(gen) {
    const it = gen();
    const state = it.next();
    function next(state) {
        if (state.done) return;
        state.value.then(res => {
            const state = it.next(res);
            next(state);
        });
    }
    next(state);
}
```

其实也不复杂，就是在then函数的回调中(其实也是回调啦)移动Generator的指针，然后递归调用，继续移动指针。当然，需要有一个停止递归的逻辑。

以下是暖男版。

```javascript
function isObject(value) {
    return Object === value.constructor;
}

function isGenerator(obj) {
    return typeof obj.next === 'function' && typeof obj.throw === 'function';
}

function isGeneratorFunction(obj) {
    const constructor = obj.constructor;
    if (!constructor) return false;
    if (constructor.name === GeneratorFunction || constructor.displayName === 'GeneratorFunction') return true;
    return isGenerator(constructor.prototype);
}

function isPromise(obj) {
    return typeof obj.then === 'function';
}

function toPromise(obj) {
    if (!obj) return obj;
    if (isPromise(obj)) return obj;
    if (isGenerator(obj) || isGeneratorFunction(obj)) {
        return co.call(this, obj);
    }
    if (typeof obj === 'function') {
        return thunkToPromise.call(this, obj);
    }
    if (Array.isArray(obj)) {
        return arrayToPromise.call(this, obj);
    }
    if (isObject(obj)) {
        return objectToPromise.call(this, obj);
    }
    return obj;
}

function typeError(value) {
    return new TypeError(`You may only yield a function, promise, generator, array, or object, but the following object was passed: "${String(value)}"`);
}

function co(gen) {
    const ctx = this;
    return new Promise((resolve, reject) => {
        let it;
        if (typeof gen === 'function') {
            it = gen.call(ctx);
        }
        if (!it || typeof it.next !== 'function') {
            return resolve(it);
        }
        onFulfilled();
        function onFulfilled(res) {
            let ret;
            try {
                ret = it.next(res);
            } catch (err) {
                return reject(err);
            }
            next(ret);
        }

        function onRejected(res) {
            let ret;
            try {
                ret = it.throw(res);
            } catch (err) {
                return reject(err);
            }
            next(ret);
        }
        function next(ret) {
            if (ret.done) {
                return resolve(ret.value);
            }
            const value = toPromise.call(ctx, ret.value);
            if (value && isPromise(value)) {
                return value.then(onFulfilled, onRejected);
            }
            return onRejected(typeError(ret.value));
        }
    });
}
```

`co`是一个真正的异步解决方案，因为它暴露的接口足够简单。

```javascript
import co from './co';

function fetchByName(name) {
    const url = `https://api.github.com/users/${name}/repos`;
    return fetch(url).then(res => res.json());
}

function *gen() {
    const value1 = yield fetchByName('veedrin');
    console.log(value1);
    const value2 = yield fetchByName('tj');
    console.log(value2);
}

co(gen);
```

直接把Generator函数传入`co`函数即可，太优雅了。


Async 专题 03 —— 状态机


Promise是一个表现为状态机的异步容器。

它有以下几个特点：

- 状态不受外界影响。Promise只有三种状态：`pending`(进行中)、`fulfilled`(已成功)和`rejected`(已失败)。状态只能通过Promise内部提供的`resolve()`和`reject()`函数改变。
- 状态只能从`pending`变为`fulfilled`或者从`pending`变为`rejected`。并且一旦状态改变，状态就会被冻结，无法再次改变。

```javascript
new Promise((resolve, reject) => {
    reject('reject');
    setTimeout(() => resolve('resolve'), 5000);
}).then(console.log, console.error);

// 不要等了，它只会打印一个 reject
```

- 如果状态发生改变，任何时候都可以获得最终的状态，即便改变发生在前。这与事件监听完全不一样，事件监听只能监听之后发生的事件。

```javascript
const promise = new Promise(resolve => resolve('biu'));
promise.then(console.log);
setTimeout(() => promise.then(console.log), 5000);

// 打印 biu，相隔大约 5 秒钟后又打印 biu
```

正是源于这些特点，Promise才敢于称自己为一个`承诺`。

## 同步代码与异步代码

Promise是一个异步容器，那哪些部分是同步执行的，哪些部分是异步执行的呢？

```javascript
console.log('kiu');

new Promise((resolve, reject) => {
    console.log('miu');
    resolve('biu');
    console.log('niu');
}).then(console.log, console.error);

console.log('piu');
```

我们看执行结果。

```
kiu
miu
niu
piu
biu
```

可以看到，Promise构造函数的参数函数是完完全全的同步代码，只有状态改变触发的then回调才是异步代码。为啥说Promise是一个异步容器？它不关心你给它装的是啥，它只关心状态改变后的异步执行，并且承诺给你一个稳定的结果。

从这点来看，Promise真的只是一个异步容器而已。

## Promise.prototype.then()

then方法接受两个回调作为参数，状态变成`fulfilled`时会触发第一个回调，状态变成`rejected`时会触发第二个回调。你可以认为then回调是Promise这个异步容器的界面和输出，在这里你可以获得你想要的结果。

then函数可以实现链式调用吗？可以的。

但你想一下，then回调触发的时候，Promise的状态已经冻结了。这时候它就是被打开盒子的薛定谔的猫，它要么是死的，要么是活的。也就是说，它不可能再次触发then回调。

那then函数是如何实现链式调用的呢？

原理就是then函数自身返回的是一个新的Promise实例。再次调用then函数的时候，实际上调用的是这个新的Promise实例的then函数。

既然Promise只是一个异步容器而已，换一个容器也不会有什么影响。

```javascript
const promiseA = new Promise((resolve, reject) => resolve('biu'));

const promiseB = promiseA.then(value => {
    console.log(value);
    return value;
});

const promiseC = promiseB.then(console.log);
```

结果是打印了两个 biu。

```javascript
const promiseA = new Promise((resolve, reject) => resolve('biu'));

const promiseB = promiseA.then(value => {
    console.log(value);
    return Promise.resolve(value);
});

const promiseC = promiseB.then(console.log);
```

`Promise.resolve()`我们后面会讲到，它返回一个状态是`fulfilled`的Promise实例。

这次我们手动返回了一个状态是`fulfilled`的新的Promise实例，可以发现结果和上一次一模一样。说明then函数悄悄的将`return 'biu'`转成了`return Promise.resolve('biu')`。如果没有返回值呢？那就是转成`return Promise.resolve()`，反正得转成一个新的状态是`fulfilled`的Promise实例返回。

这就是then函数返回的总是一个新的Promise实例的内部原理。

想要让新Promise实例的状态从`pending`变成`rejected`，有什么办法吗？毕竟then方法也没给我们提供`reject`方法。

```javascript
const promiseA = new Promise((resolve, reject) => resolve('biu'));

const promiseB = promiseA.then(value => {
    console.log(value);
    return x;
});

const promiseC = promiseB.then(console.log, console.error);
```

查看这里的输出结果。

```
biu
ReferenceError: x is not defined
    at <anonymous>:6:5
```

只有程序本身发生了错误，新Promise实例才会捕获这个错误，并把错误暗地里传给`reject`方法。于是状态从`pending`变成`rejected`。

## Promise.prototype.catch()

catch方法，顾名思义是用来捕获错误的。它其实是then方法某种方式的语法糖，所以下面两种写法的效果是一样的。

```javascript
new Promise((resolve, reject) => {
    reject('biu');
}).then(
    undefined,
    error => console.error(error),
);
```

```javascript
new Promise((resolve, reject) => {
    reject('biu');
}).catch(
    error => console.error(error),
);
```

Promise内部的错误会静默处理。你可以捕获到它，但错误本身已经变成了一个消息，并不会导致外部程序的崩溃和停止执行。

下面的代码运行中发生了错误，所以容器中后面的代码不会再执行，状态变成`rejected`。但是容器外面的代码不受影响，依然正常执行。

```javascript
new Promise((resolve, reject) => {
    console.log(x);
    console.log('kiu');
    resolve('biu');
}).then(console.log, console.error);

setTimeout(() => console.log('piu'), 5000);
```

所以大家常常说"Promise会吃掉错误"。

如果状态已经冻结，即便运行中发生了错误，Promise也会忽视它。

```javascript
new Promise((resolve, reject) => {
    resolve('biu');
    console.log(x);
}).then(console.log, console.error);

setTimeout(() => console.log('piu'), 5000);
```

Promise的错误如果没有被及时捕获，它会往下传递，直到被捕获。中间没有捕获代码的then函数就被忽略了。

```javascript
new Promise((resolve, reject) => {
    console.log(x);
    resolve('biu');
}).then(
    value => console.log(value),
).then(
    value => console.log(value),
).then(
    value => console.log(value),
).catch(
    error => console.error(error),
);
```

## Promise.prototype.finally()

所谓finally就是一定会执行的方法。它和then或者catch不一样的地方在于，finally方法的回调函数不接受任何参数。也就是说，它不关心容器的状态，它只是一个兜底的。

```javascript
new Promise((resolve, reject) => {
    // 逻辑
}).then(
    value => {
        // 逻辑
        console.log(value);
    },
    error => {
        // 逻辑
        console.error(error);
    }
);
```

```javascript
new Promise((resolve, reject) => {
    // 逻辑
}).finally(
    () => {
        // 逻辑
    }
);
```

如果有一段逻辑，无论状态是`fulfilled`还是`rejected`都要执行，那放在then函数中就要写两遍，而放在finally函数中就只需要写一遍。

另外，别被finally这个名字带偏了，它不一定要定义在最后的。

```javascript
new Promise((resolve, reject) => {
    resolve('biu');
}).finally(
    () => console.log('piu'),
).then(
    value => console.log(value),
).catch(
    error => console.error(error),
);
```

finally函数在链条中的哪个位置定义，就会在哪个位置执行。从语义化的角度讲，`finally`不如叫`anyway`。

## Promise.all()

它接受一个由Promise实例组成的数组，然后生成一个新的Promise实例。这个新Promise实例的状态由数组的整体状态决定，只有数组的整体状态都是`fulfilled`时，新Promise实例的状态才是`fulfilled`，否则就是`rejected`。这就是`all`的含义。

```javascript
Promise.all([Promise.resolve(1), Promise.resolve(2), Promise.resolve(3)]).then(
    values => console.log(values),
).catch(
    error => console.error(error),
);
```

```javascript
Promise.all([Promise.resolve(1), Promise.reject(2), Promise.resolve(3)]).then(
    values => console.log(values),
).catch(
    error => console.error(error),
);
```

数组中的项目如果不是一个Promise实例，all函数会将它封装成一个Promise实例。

```javascript
Promise.all([1, 2, 3]).then(
    values => console.log(values),
).catch(
    error => console.error(error),
);
```

## Promise.race()

它的使用方式和`Promise.all()`类似，但是效果不一样。

`Promise.all()`是只有数组中的所有Promise实例的状态都是`fulfilled`时，它的状态才是`fulfilled`，否则状态就是`rejected`。

而`Promise.race()`则只要数组中有一个Promise实例的状态是`fulfilled`，它的状态就会变成`fulfilled`，否则状态就是`rejected`。

就是`&&`和`||`的区别是吧。

它们的返回值也不一样。

`Promise.all()`如果成功会返回一个数组，里面是对应Promise实例的返回值。

而`Promise.race()`如果成功会返回最先成功的那一个Promise实例的返回值。

```javascript
function fetchByName(name) {
    const url = `https://api.github.com/users/${name}/repos`;
    return fetch(url).then(res => res.json());
}

const timingPromise = new Promise((resolve, reject) => {
    setTimeout(() => reject(new Error('网络请求超时')), 5000);
});

Promise.race([fetchByName('veedrin'), timingPromise]).then(
    values => console.log(values),
).catch(
    error => console.error(error),
);
```

上面这个例子可以实现网络超时触发指定操作。

## Promise.resolve()

它的作用是接受一个值，返回一个状态是`fulfilled` 的Promise实例。

```javascript
Promise.resolve('biu');
```

```javascript
new Promise(resolve => resolve('biu'));
```

它是以上写法的语法糖。

## Promise.reject()

它的作用是接受一个值，返回一个状态是`rejected`的Promise实例。

```javascript
Promise.reject('biu');
```

```javascript
new Promise((resolve, reject) => reject('biu'));
```

它是以上写法的语法糖。

## 嵌套Promise

如果Promise有嵌套，它们的状态又是如何变化的呢？

```javascript
const promise = Promise.resolve(
    (() => {
        console.log('a');
        return Promise.resolve(
            (() => {
                console.log('b');
                return Promise.resolve(
                    (() => {
                        console.log('c');
                        return new Promise(resolve => {
                            setTimeout(() => resolve('biu'), 3000);
                        });
                    })()
                )
            })()
        );
    })()
);

promise.then(console.log);
```

可以看到，例子中嵌套了四层Promise。别急，我们先回顾一下没有嵌套的情况。

```javascript
const promise = Promise.resolve('biu');

promise.then(console.log);
```

我们都知道，它会在微任务时机执行，肉眼几乎看不到等待。

但是嵌套了四层Promise的例子，因为最里层的Promise需要等待几秒才resolve，所以最外层的Promise返回的实例也要等待几秒才会打印日志。也就是说，只有最里层的Promise状态变成`fulfilled`，最外层的Promise状态才会变成`fulfilled`。

如果你眼尖的话，你就会发现这个特性就是Koa中间件机制的精髓。

Koa中间件机制也是必须得等最后一个中间件resolve(如果它返回的是一个Promise实例的话)之后，才会执行洋葱圈另外一半的代码。

```javascript
function compose(middleware) {
    return function(context, next) {
        let index = -1;
        return dispatch(0);
        function dispatch(i) {
            if (i <= index) return Promise.reject(new Error('next() called multiple times'));
            index = i;
            let fn = middleware[i];
            if (i === middleware.length) fn = next;
            if (!fn) return Promise.resolve();
            try {
                return Promise.resolve(fn(context, function next() {
                    return dispatch(i + 1);
                }));
            } catch (err) {
                return Promise.reject(err);
            }
        }
    }
}
```


Async 专题 02 —— 迟到的承诺


也许我们都听说过JavaScript是事件驱动的这种说法。各种异步任务通过事件的形式和主线程通信，保证网页流畅的用户体验。而异步可以说是JavaScript最伟大的特性之一(也许没有之一)。

现在我们就从Chrome浏览器的主要进程入手，深入的理解这个机制是如何运行的。

## Chrome浏览器的主要进程

我们看一下Chrome浏览器都有哪些主要进程。

- Browser进程。这是浏览器的主进程。

- 第三方插件进程。

- GPU进程。

- Renderer进程。

大家都说Chrome浏览器是内存怪兽，因为它的每一个页面都是一个Renderer进程，其实这种说法是不对的。实际上，Chrome支持好几种进程模型。

- `Process-per-site-instance`。每打开一个网站，然后从这个网站链开的一系列网站都属于一个进程。这也是Chrome的默认进程模型。

- `Process-per-site`。同域名范畴的网站属于一个进程。

- `Process-per-tab`。每一个页面都是一个独立的进程。这就是外界盛传的进程模型。

- `Single Process`。传统浏览器的单进程模型。

## 浏览器内核

现在我们知道，除了相关联的页面可能会合并为一个进程外，我们可以简单的认为每个页面都会开启一个新的Renderer进程。那么这个进程里跑的程序又是什么呢？就是我们常常说的浏览器内核，或者说渲染引擎。确切的说，是浏览器内核的一个实例。Chrome浏览器的渲染引擎叫`Blink`。

由于浏览器主要是用来浏览网页的，所以虽然Browser进程是浏览器的主进程，但它充当的只是一个管家的角色，真正的一线业务大拿还得看Renderer进程。这也是跑在Renderer进程里的程序被称为浏览器内核(实例)的原因。

介绍Chrome浏览器的进程系统只是为了引出Renderer进程，接下来我们只需要关注浏览器内核与Renderer进程就可以了。

## Renderer进程的主要线程

Renderer进程手下又有好多线程，它们各司其职。

- GUI渲染线程。

- JavaScript引擎线程。对于Chrome浏览器而言，这个线程上跑的就是威震海内的V8引擎。

- 事件触发线程。

- 定时器线程。

- 异步HTTP请求线程。

## 调用栈

进入主题之前，我们先引入调用栈(call stack)的概念，调用栈是JavaScript引擎执行程序的一种机制。为什么要有调用栈呢？我们举个例子。

```javascript
const str = 'biu';

console.log('1');

function a() {
    console.log('2');
    b();
    console.log('3');
}

function b() {
    console.log('4');
}

a();
```

我们都知道打印的顺序是`1 2 4 3`。

问题在于，当执行到`b函数`的时候，我需要记住`b函数`的调用位置信息，也就是执行上下文。否则执行完`b函数`之后，引擎可能就忘了执行`console.log('3')`了。调用栈就是用来干这个的，每调用一层函数，引擎就会生成它的栈帧，栈帧里保存了执行上下文，然后将它压入调用栈中。栈是一个后进先出的结构，直到最里层的函数调用完，引擎才开始将最后进入的栈帧从栈中弹出。

| 1                | 2    | 3                | 4    | 5                | 6    | 7                | 8    |
| ---------------- | ---- | ---------------- | ---- | ---------------- | ---- | ---------------- | ---- |
| -                | -    | -                | -    | console.log('4') | -    | -                | -    |
| -                | -    | console.log('2') | b()  | b()              | b()  | console.log('3') | -    |
| console.log('1') | a()  | a()              | a()  | a()              | a()  | a()              | a()  |

可以看到，当有嵌套函数调用的时候，栈帧会经历逐渐叠加又逐渐消失的过程，这就是所谓的后进先出。

同时也要注意，诸如`const str = 'biu'`的变量声明是不会入栈的。

调用栈也要占用内存，所以如果调用栈过深，浏览器会报`Uncaught RangeError: Maximum call stack size exceeded`错误。

## webAPI

现在我们进入主题。

JavaScript引擎将代码从头执行到尾，不断的进行压栈和出栈操作。除了ECMAScript语法组成的代码之外，我们还会写哪些代码呢？不错，还有JavaScript运行时给我们提供的各种webAPI。运行时(runtime)简单讲就是JavaScript运行所在的环境。

我们重点讨论三种webAPI。

```javascript
const url = 'https://api.github.com/users/veedrin/repos';
fetch(url).then(res => res.json()).then(console.log);
```

```javascript
const url = 'https://api.github.com/users/veedrin/repos';
const xhr = new XMLHttpRequest();
xhr.open('GET', url, true);
xhr.onload = () => {
    if (xhr.status === 200) {
        console.log(xhr.response);
    }
}
xhr.send();
```

发起异步的HTTP请求，这几乎是一个网页必要的模块。我们知道HTTP请求的速度和结果取决于当前网络环境和服务器的状态，JavaScript引擎无法原地等待，所以浏览器得另开一个线程来处理HTTP请求，这就是之前提到的`异步HTTP请求线程`。

```javascript
const timeoutId = setTimeout(() => {
    console.log(Date.now());
    clearTimeout(timeoutId);
}, 5000);
```

```javascript
const intervalId = setInterval(() => {
    console.log(Date.now());
}, 1000);
```

```javascript
const immediateId = setImmediate(() => {
    console.log(Date.now());
    clearImmediate(immediateId);
});
```

定时器也是一个棘手的问题。首先，JavaScript引擎同样无法原地等待；其次，即便不等待，JavaScript引擎也得执行后面的代码，根本无暇给定时器定时。所以于情于理，都得为定时器单独开一个线程，这就是之前提到的`定时器线程`。

```javascript
const $btn = document.getElementById('btn');
$btn.addEventListener('click', console.log);
```

按道理来讲，DOM事件没什么异步动作，直接绑定就行了，不会影响后面代码的执行。

别急，我们来看一个例子。

```javascript
const $btn = document.getElementById('btn');
$btn.addEventListener('click', console.log);
const timeoutId = setTimeout(() => {
    for (let i = 0; i < 10000; i++) {
        console.log('biu');
    }
    clearTimeout(timeoutId);
}, 5000);
```

运行代码，先绑定DOM事件，大约5秒钟后开启一个循环。注意，如果在循环结束之前点击按钮，浏览器控制台会打印什么呢？

结果是先打印10000个`biu`，接着会打印`Event`对象。

试想一下，你点击按钮的时候，JavaScript引擎还在处理该死的循环，根本没空理你。那为什么点击事件能够被响应呢(虽然有延时)？肯定是有另外一个线程在监听DOM事件。这就是之前提到的`事件触发线程`。

## 任务队列

好的，现在我们知道有几类webAPI是单独的线程在处理。但是，处理完之后的回调总归是要由`JavaScript引擎线程`来执行的吧？这些线程是如何与`JavaScript引擎线程`通信的呢？

这就要提到大名鼎鼎的任务队列(Task Queue)。

其实无论是HTTP请求还是定时器还是DOM事件，我们都可以统称它们为事件。很好，各自的线程把各自的webAPI处理完，完成之后怎么办呢？它要把相应的回调函数放入一个叫做任务队列的数据结构里。队列和栈不一样，队列是先进先出的，讲究一个先来后到的顺序。

> 有很多文章认为`任务队列`是由`JavaScript引擎线程`维护的，也有很多文章认为`任务队列`是由`事件触发线程`维护的。
>
> 根据上文的描述，`事件触发线程`是专门用来处理DOM事件的。
>
> 然后我们来论证，为什么`任务队列`不是由`JavaScript引擎线程`维护的。假如`JavaScript引擎线程`在执行代码的同时，其他线程要给任务队列添加事件，这时候它哪忙得过来呢？
>
> 所以根据我的理解，任务队列应该是由一个专门的线程维护的。我们就叫它`任务队列线程`吧。

## 事件循环

等`JavaScript引擎线程`把所有的代码执行完了一遍，现在它可以歇着了吗？也许吧，接下来它还有一个任务，就是不停的去轮询任务队列，如果任务队列是空的，它就可以歇一会，如果任务队列中有回调，它就要立即执行这些回调。

这个过程会一直进行，它就是事件循环(Event Loop)。

我们总结一下这个过程：

- 第一阶段，`JavaScript引擎线程`从头到尾把脚本代码执行一遍，碰到需要其他线程处理的代码则交给其他线程处理。
- 第二阶段，`JavaScript引擎线程`专注于处理事件。它会不断的去轮询任务队列，执行任务队列中的事件。这个过程又可以分解为`轮询任务队列-执行任务队列中的事件-更新页面视图`的无限往复。对，别忘了更新页面视图(如果需要的话)，虽然更新页面视图是`GUI渲染线程` 处理的。

这些事件，在任务队列里面也被称为任务。但是事情没这么简单，任务还分优先级，这就是我们常听说的宏任务和微任务。

#### 宏任务

既然任务分为宏任务和微任务，那是不是得有两个任务队列呢？

此言差矣。

首先我们得知道，事件循环可不止一个。除了window event loop之外，还有worker event loop。并且同源的页面会共享一个window event loop。

> A window event loop is the event loop used by similar-origin window agents. User agents may share an event loop across similar-origin window agents.

其次我们要区分任务和任务源。什么叫任务源呢？就是这个任务是从哪里来的。是从`addEventListener`来的呢，还是从`setTimeout`来的。为什么要这么区分呢？比如键盘和鼠标事件，就要把它的响应优先级提高，以便尽可能的提高网页浏览的用户体验。虽然都是任务，命可分贵贱呢！

所以不同任务源的任务会放入不同的任务队列里，浏览器根据自己的算法来决定先取哪个队列里的任务。

总结起来，宏任务有至少一个任务队列，微任务只有一个任务队列。

#### 微任务

哪些异步事件是微任务？Promise的回调、MutationObserver的回调以及nodejs中process.nextTick的回调。

```html
<div id="outer">
    <div id="inner">请点击</div>
</div>
```

```javascript
const $outer = document.getElementById('outer');
const $inner = document.getElementById('inner');

new MutationObserver(() => {
    console.log('mutate');
}).observe($inner, {
    childList: true,
});

function onClick() {
    console.log('click');
    setTimeout(() => console.log('timeout'), 0);
    Promise.resolve().then(() => console.log('promise'));
    $inner.innerHTML = '已点击';
}

$inner.addEventListener('click', onClick);
$outer.addEventListener('click', onClick);
```

我们先来看执行顺序。

```
click
promise
mutate
click
promise
mutate
timeout
timeout
```

整个执行过程是怎样的呢？

- 从头到尾初始执行脚本代码。给DOM元素添加事件监听。
- 用户触发内元素的DOM事件，同时冒泡触发外元素的DOM事件。将内元素和外元素的DOM事件回调添加到宏任务队列中。
- 因为此时调用栈中是空闲的，所以将内元素的DOM事件回调放入调用栈。
- 执行回调，此时打印`click`。同时将setTimeout的回调放入宏任务队列，将Promise的回调放入微任务队列。因为修改了DOM元素，触发MutationObserver事件，将MutationObserver的回调放入微任务队列。回顾一下，现在宏任务队列里有两个回调，分别是`外元素的DOM事件回调`和`setTimeout的回调`；微任务队列里也有两个回调，分别是`Promise的回调`和`MutationObserver的回调`。
- 依次将微任务队列中的回调放入调用栈，此时打印`promise`和`mutate`。
- 将外元素的DOM事件回调放入调用栈。执行回调，此时打印`click`。因为两个DOM事件回调是一样的，过程不再重复。再次回顾一下，现在宏任务队列里有两个回调，分别是两个`setTimeout的回调`；微任务队列里也有两个回调，分别是`Promise的回调`和`MutationObserver的回调`。
- 依次将微任务队列中的回调放入调用栈，此时打印`promise`和`mutate`。
- 最后依次将setTimeout的回调放入调用栈执行，此时打印两次`timeout`。

规律是什么呢？宏任务与宏任务之间，积压的所有微任务会一次性执行完毕。这就好比超市排队结账，轮到你结账的时候，你突然想顺手买一盒冈本。难道超市会要求你先把之前的账结完，然后重新排队吗？不会，超市会顺便帮你把冈本的账也结了。这样效率更高不是么？虽然不知道内部的处理细节，但是我觉得标准区分两种任务类型也是出于性能的考虑吧。

```javascript
$inner.click();
```

如果DOM事件不是用户触发的，而是程序触发的，会有什么不一样吗？

```
click
click
promise
mutate
promise
timeout
timeout
```

严格的说，这时候并没有触发事件，而是直接执行`onClick`函数。翻译一下就是下面这样的效果。

```
onClick();
onClick();
```

这样就解释了为什么会先打印两次`click`。而MutationObserver会合并多个事件，所以只打印一次`mutate`。所有微任务依然会在下一个宏任务之前执行，所以最后才打印两次`timeout`。

#### 更新页面视图

我们再来看一个例子。

```javascript
const $btn = document.getElementById('btn');

function onClick() {
    setTimeout(() => {
        new Promise(resolve => resolve('promise 1')).then(console.log);
        new Promise(resolve => resolve('promise 2')).then(console.log);
        console.log('timeout 1');
        $btn.style.color = '#f00';
    }, 1000);
    setTimeout(() => {
        new Promise(resolve => resolve('promise 1')).then(console.log);
        new Promise(resolve => resolve('promise 2')).then(console.log);
        console.log('timeout 2');
    }, 1000);
    setTimeout(() => {
        new Promise(resolve => resolve('promise 1')).then(console.log);
        new Promise(resolve => resolve('promise 2')).then(console.log);
        console.log('timeout 3');
    }, 1000);
    setTimeout(() => {
        new Promise(resolve => resolve('promise 1')).then(console.log);
        new Promise(resolve => resolve('promise 2')).then(console.log);
        console.log('timeout 4');
        // alert(1);
    }, 1000);
    setTimeout(() => {
        new Promise(resolve => resolve('promise 1')).then(console.log);
        new Promise(resolve => resolve('promise 2')).then(console.log);
        console.log('timeout 5');
        // alert(1);
    }, 1000);
    setTimeout(() => {
        new Promise(resolve => resolve('promise 1')).then(console.log);
        new Promise(resolve => resolve('promise 2')).then(console.log);
        console.log('timeout 6');
    }, 1000);
    new MutationObserver(() => {
        console.log('mutate');
    }).observe($btn, {
        attributes: true,
    });
}

$btn.addEventListener('click', onClick);
```

当我在第4个setTimeout添加alert，浏览器被阻断时，样式还没有生效。

> 有很多人说，每一个宏任务执行完并附带执行完累计的微任务(我们称它为一个宏任务周期)，这时会有一个更新页面视图的窗口期，给更新页面视图预留一段时间。

但是我们的例子也看到了，每一个setTimeout都是一个宏任务，浏览器被阻断时事件循环都好几轮了，但样式依然没有生效。可见这种说法是不准确的。

而当我在第5个setTimeout添加alert，浏览器被阻断时，有很大的概率(并不是一定)样式会生效。这说明什么时候更新页面视图是由浏览器决定的，并没有一个准确的时机。

#### 总结

JavaScript引擎首先从头到尾初始执行脚本代码，不必多言。

如果初始执行完毕后有微任务，则执行微任务(为什么这里不属于事件循环？后面会讲到)。

之后就是不断的事件循环。

首先到宏任务队列里找宏任务，宏任务队列又分好多种，浏览器自己决定优先级。

被放入调用栈的某个宏任务，如果它的代码中又包含微任务，则执行所有微任务。

更新页面视图没有一个准确的时机，是每个宏任务周期后更新还是几个宏任务周期后更新，由浏览器决定。

> 也有一种说法认为：从头到尾初始执行脚本代码也是一个任务。

如果我们认可这种说法，则整个代码执行过程都属于事件循环。

初始执行就是一个宏任务，这个宏任务里面如果有微任务，则执行所有微任务。

浏览器自己决定更新页面视图的时机。

不断的往复这个过程，只不过之后的宏任务是事件回调。

> 第二种解释好像更说得通。因为第一种解释会有一段微任务的执行不在事件循环里，这显然是不对的。


Async 专题 01 —— 事件循环

Grid 专题 01 —— 二维布局模型 Grid


Flexbox叫弹性盒模型，它的使用场景主要是屏幕自适应布局和取代浮动布局。

细节性的知识需要大量实践，系统性的知识则需要真正理解系统。我认为Flexbox就属于系统性的知识。所以这篇文章从概念入手，力求做到只要阅读一遍，就可以让开发者心中有乾坤。

## 一维布局模型

你他妈可能是`三体`看多了吧，啥叫一维布局模型？

一维布局模型，简单讲就是，在`主轴`方向确定的情况下，只有`行`，没有`列`。

我们熟悉的二维布局模型有哪些呢？有`display: table`和`display: grid`。而我们今天要讲的`display: flex`就是妥妥的一维布局模型了。

直接看图。

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/01.png)

可以看到，Flexbox有`行`的概念，却没有`列`的概念。这导致它的表达能力是受限的。

## 概念

我们如何确定一条短线是中文的`一`还是阿拉伯数字的`1`呢？

你可能觉得我在搞笑。一眼看过去，横向的不就是中文的`一`，纵向的不就是阿拉伯数字的`1`么。

是的。那是因为我们遵循着一些默认的约定：两眼连成的线确定了水平方向。

Flexbox也是这个道理。它是一个一维布局模型，我们就要找到确定仅有的维度的那根线。

这就引出了Flexbox的第一个概念：主轴(mian axis)与交叉轴(cross axis)。主轴就是那根仅有的维度线。两眼连成的线与主轴方向保持平行，这就是肉眼看待Flexbox的正确方式。否则有时候它会显得很别扭。

然后我们再来说弹性盒子。既然它是一个盒子，那肯定得有容器，也得有内容。

也就引出了Flexbox的第二个概念：弹性容器(flex container)与弹性项目(flex item)。

你可以将弹性容器理解为冷战时期的柏林，各方国际政治势力自然就是若干弹性项目了。几个国际大流氓聚在一起开会讨论什么呢？当然是开会讨论如何瓜分柏林咯。是的，弹性盒模型讨论的就是弹性项目如何瓜分弹性容器这一温馨的话题。

上一小节我们提到过，Flexbox是一维布局模型。它带来的结果就是Flexbox有`行`的概念，却没有`列`的概念。

所以引出Flexbox的第三个概念：行(line)。

直接看图。

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/02.png)

## 最小长度

如果弹性容器有富余空间，那好说，大家分就是了。而如果弹性容器空间不够，弹性项目不仅没得分，大家还得挤一挤。那么问题就来了，挤不是无限制的挤，咱们就来探讨一下，挤到什么程度，是可忍孰不可忍？

举个例子。

```css
.container {
    display: flex;
    width: 850px;
    padding: 5px;
}
.container .item {
    width: 200px;
    height: 50px;
    margin: 5px;
}
.container .item:nth-child(2) {
    width: 1000px;
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/03.png)

两个弹性项目的长度加起来的和已经超过了弹性容器，所以不得不挤压。挤压的比率咱们先不考虑，咱们先观察挤压的方式。有没有发现红色部分都有不同程度的收缩，但是黄色部分却岿然不动？

黄色部分是什么？是弹性容器的`padding`和弹性项目的`margin`。盒子模型咱们都了解吧，除了`padding`、`margin`和`border`之外，是不是只剩`content`了？

咱们可以大胆猜测，Flexbox只敢欺负盒子模型的`content`，其余都是大爷，惹不起。

别急，再来验证一下。

```css
.container {
    display: flex;
    width: 850px;
    padding: 5px;
}
.container .item {
    width: 200px;
    height: 50px;
    margin: 5px;
}
.container .item:nth-child(2) {
    width: 1000px;
    padding: 0 450px;
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/04.png)

这下是不是很清楚了？第一个弹性项目的`content`长度已经变成了0；第二个也好不到哪去，因为盒子长度都被`padding`占据，它的`content`长度实际上也是0。都把人家挤破产了，却丝毫不敢动其他的属性，势利眼无疑了。

我们再来看一个有意思的例子。

```css
.container {
    display: flex;
    width: 850px;
    padding: 5px;
}
.container .item {
    width: 200px;
    height: 50px;
    margin: 5px;
}
.container .item:nth-child(2) {
    width: 1000px;
    padding: 0 300px;
}
.container .item .inner {
    width: 500px;
    height: 100%;
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/05.png)

我在第二个弹性项目中放了一个长`500px`的元素，结果你猜怎么着，弹性项目的`padding`竟然有一部分和元素重合了。连子元素都未能幸免。

一般来说盒子模型的`content`都是被文字撑开的，我们最后再来看看文字的情况。

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/06.png)

在弹性项目显式设置了宽度的情况下，弹性项目并不能完全包裹文字。也就是说文字也帮不了它，既然它声明了宽度，文字撑开的长度最多不能超过显式声明的宽度，超出的文字只能溢出。

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/07.png)

而没有显式声明宽度的情况，文字的宽度就是弹性项目盒子模型的`content`，Flexbox也拿它没办法。

> 总结一下：当富余空间不够时，Flexbox只会挤压弹性项目的`content`，其余如`padding` 、`margin`和`border`完全不受影响。同时弹性项目没有显式声明宽度的情况下，Flexbox也不会挤压文字。

## display

从这里开始，我们就要讲具体的CSS属性了。

`display`有两个和Flexbox相关的属性，分别是`display: flex`和`display: inline-flex`。

对于容器内部的项目来说，效果是一样的。它们的区别在于容器自身应该以块元素还是行内元素的身份立命。包括`table`也有这样的区分，就不多讲了。

## flex-direction

这个属性声明的是主轴的方位和方向。

首先，主轴可不一定是水平的，主轴切换了那可就什么都变了。

其次，主轴声明的信息有两个，分别是：

- 它是水平的还是垂直的？
- 它在水平或垂直维度上是从左到右还是从右到左？

所以这里也涉及到四个属性值。

```css
.container {
    flex-direction: row /*default*/ | row-reverse | column | column-reverse;
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/08.png)

## flex-wrap

这个属性声明的是当容器中的项目一行放不下的时候，是让大家挤一挤呢，还是换行。

其实这里也包含两个信息：

- 要不要换行？
- 如果需要换行就会形成多行，多行是从上到下排列还是从下到上排列？

```css
.container {
    flex-wrap: nowrap /*default*/ | wrap | wrap-reverse;
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/09.png)

如果把`flex-direction`和`flex-wrap`结合起来，大家会不会懵逼？上上下下左左右右。其实不管它怎么reverse，`flex-direction`反转的是主轴的方向，`flex-wrap`反转的交叉轴的方向。

抓住一些概念性的东西，就不会懵逼了。

## flex-flow

这是一个集合属性，可以同时定义`flex-direction`和`flex-wrap`。

也就是说，这一个属性可以一站式声明主轴和交叉轴的特性。

```css
.container {
    flex-flow: row-reverse wrap-reverse;
}
```

## justify-content

这个属性声明每行内的项目如何水平对齐。

把弹性容器一行内的项目想象成一行行内元素，`justify-content`和`text-align`的食用方式是一样的。

```css
.container {
    justify-content: flex-start /*default*/ | flex-end | center | space-between | space-around | space-evenly;
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/10.png)

`flex-start`、`flex-end`和`center`非常表意，咱们按下不表。

解释一下后面三个属性值：

- `space-between`表示两头的项目对齐容器壁，项目与项目之间的空隙平均分配。所谓的`between`指的就是项目之间。
- `space-around`表示两头的项目与容器壁保留一个单位的空隙，项目与项目之间保持两个单位的空隙。`around`翻译成中文是`周围`，指的就是每个项目左右两边的空隙平均分配。
- `space-evenly`表示两头的项目与容器壁之间的空隙和项目与项目之间的空隙都保持一个单位。`evenly`翻译成中文是`均匀`，指的是所有空隙平均分配。

## align-items

这个属性声明每行内的项目如何垂直对齐。

```css
.container {
    align-items: stretch /*default*/ | flex-start | flex-end | center | baseline;
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/11.png)

这里有一个问题，如果弹性项目显式的声明了高度，那`stretch`将不再起作用。所以这里的例子，我往项目中加了一个子元素，把高度显式的声明在子元素上，这样项目的高度就是被撑开的。

```html
<div class="container">
    <div class="item"><div class="inner">1</div></div>
    <div class="item"><div class="inner">2</div></div>
    <div class="item"><div class="inner">3</div></div>
</div>
```

可以看到，默认情况下，行内的弹性项目会拉伸，相当于声明了高度`100%`。一旦项目显式的声明了高度，拉伸就不再起作用了。

## align-content

这个属性将容器的一行视为最小单位。它声明的是如果容器的交叉轴方向有富余空间，每行应该如何垂直对齐。

```css
.container {
    align-content: stretch /*default*/ | flex-start | flex-end | center | space-between | space-around | space-evenly;
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/12.png)

这里也一样，如果弹性项目显式的声明了高度，那`stretch`将不再起作用。

同时有两点需要注意：

- 弹性容器需要显式的声明高度，而且高度必须高于所有行的高度和，否则去哪来的富余空间呢？
- 如果容器内只有一行，也就是说不需要换行或者不允许换行，那`align-content`属性将无法生效，因为它是作用于行的，只有一行也敢叫老子跑一趟？

## 为什么没有`justify-items`

如果你同时了解`display: flex`和`display: grid`，也许你会发现它们都有`xx-items`和`xx-content`属性。但是别急，再进一步深究，发现Flexbox少了一个`justify-items`。

我们先来阐述一下`xx-items`和`xx-content`作用范围有什么区别。

- `xx-items`作用于项目，这意思很明朗。
- `xx-content`又是作用于什么呢？肯定是比项目更大的单位，又联想Flexbox的`align-content`是作用于行，我们可以大胆猜测`xx-content`作用于行或者列。

点破到这里，大家应该有点眉目了吧？Flexbox是一维布局模型，它根本没有列的概念。

你说不对呀，既然Flexbox没有列的概念，那不是应该没有`justify-content`属性，而应该有`justify-items`属性么？

话是这么说，我当初也是这么认为的。

但后来仔细想一想，Flexbox的`align-items`声明的是一行内的项目如何垂直对齐，与之相对，`justify-items`声明的就应该是一列内的项目如何水平对齐。好像更离谱。而如果将弹性容器一行内的每个项目都当做一列，`justify-content`似乎就说的通了。

这就好比讨论螃蟹的螯到底是不是手一样，怎么都觉得别扭。只能找一个相对更合理的说法了。

提出这个问题没别的意思，只是想加深大家对Flexbox的理解。

## order

从这里开始，涉及到的属性都是弹性项目自身的属性。在大的格局确定的情况下，项目之间也是可以有一些腾挪空间的。

这个属性声明的是弹性项目自身的次序。只要显式声明了不是默认值0的整数，项目显示的次序将会不同于源代码定义的次序。

这个主要是留给JavaScript动态控制项目的次序用的，非动态直接修改源代码的次序就好了。

```css
.item {
    order: <integer>; /*默认值是0*/
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/13.png)

## flex-grow

这个属性声明的是弹性项目是否要瓜分行内的富余空间，以及如何瓜分。

属性值只允许正整数。

```css
.item {
    flex-grow: <number>; /*默认值是0*/
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/14.png)

首先解释一下什么是富余空间：它是在弹性容器规则和弹性项目显式宽度或者内容的共同约束下，行内剩余的水平空间。比如图例中除去`margin`、`padding`的黄色部分。

行内的富余空间是如何被瓜分的呢？

首先，弹性项目要提出申请。比如第一个项目提出`flex-grow: 1`，意思是说它想要一份富余空间。至于一份富余空间是多少像素，目前还不能确定。

等所有项目都申请完毕，计算申请的总份数。已知富余空间长度和申请总份数，就能知道一份富余空间是多少像素。

最后根据每人提出申请的份数，分配富余空间。

> 只有当行内有富余空间时，`flex-grow`属性才会生效。行内空间已经预先被瓜分完甚至不够时，该属性就管不了了。

## flex-shrink

这个属性声明的是弹性项目是否要瓜分行内的负债空间，以及如何瓜分。

属性值只允许正整数。

```css
.item {
    flex-shrink: <number>; /*默认值是1*/
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/15.png)

同样，解释一下什么是负债空间：它是在弹性容器规则和弹性项目显式宽度或者内容的共同约束下，行内短缺的水平空间。此时如果不换行的话，就要求挤压弹性项目的长度。

行内的负债空间的瓜分规则与富余空间的瓜分规则大致相同。

首先，弹性项目要提出申请。只不过这时的份额就不再是我要多少，而是我还多少。

等所有项目都申请完毕，计算申请的总份数。

这里的问题在于，计算负债空间的长度稍微比较复杂。我们在文章一开始探讨过弹性项目最小长度的话题，这里再次总结一下：

- 弹性容器只会挤压弹性项目的`content`，其余如`padding`、`margin`和`border`不受影响。
- 如果弹性项目内有文本或者固定宽度的子元素，这又分两种情况。第一种是项目本身没有显式声明宽度，则最小长度以子元素的长度为准；第二种是项目本身显式声明了宽度，则最小长度以子元素的长度为准，但不能超过项目本身的宽度。结合上面图例中最后两个例子，更容易理解(我知道你已经懵逼了)。

最后根据每人提出申请的份数，分配负债空间。就是还债。

> 为什么`flex-grow`属性的默认值是0，而`flex-shrink`属性的默认值是1呢？
>
> 因为默认情况下，如果有富余空间我可以不要的，但是有负债空间又无法换行的话，我不得不要。所以`flex-shrink`属性的默认值是1，意思就是默认情况下，如果空间不够则大家平均的被挤压。
>
> 你可以将所有项目的`flex-shrink`属性值设置为0，如此这般所有项目都铁骨铮铮、不畏强权了。见上面图例的第四个例子。

## flex-basis

这个属性声明的是预先分配给弹性项目的长度。它是`width`属性的替代品，优先级比`width`高。

```css
.item {
    flex-basis: <length> | auto; /*默认值是auto*/
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/16.png)

如果`width`和`flex-basis`都显式的声明了一个非`auto`的值，那么`flex-basis`的优先级更高。否则，哪个显式声明了就以哪个为准。

确实不太清楚制定`flex-basis`属性标准的意义何在。

它们的区别好像仅限于属性值为0的情况。`width: 0`我们都知道表示没有宽度，见上面图例的第二个例子；而`flex-basis: 0`表示以内容的宽度为宽度，见上面图例中的第三个例子。

## flex

这是一个集合属性，可以同时定义`flex-grow`、`flex-shrink`和`flex-basis`。

你可以集合三个属性的值，也可以只写`flex-grow`一个属性的值。

```css
.item {
    flex: <'flex-grow'> | <'flex-grow'> <'flex-shrink'> <'flex-basis'>;
}
```

## align-self

这个属性声明的是弹性项目自身在行内的垂直对齐方式。

“我就是我，是颜色不一样的烟火”。

```css
.item {
    align-self: auto /*default*/ | stretch | flex-start | flex-end | center | baseline;
}
```

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/flex/image/17.png)

除了`auto`之外，`align-self`的属性值和`align-items`的属性值是一样的，效果也一样。

`align-items: auto`是说我默认服从集体，不自搞一套，所以才会多这么个属性值。

> 为什么有`align-self`属性而没有`justify-self`属性呢？
>
> 这个问题我们讨论过吧？因为没有`jusifty-items`属性，所以`justify-self`属性也无从谈起。
>
> 你看人家Grid就有`justify-self`属性。

## 其他

有一个小游戏[Flexbox Froggy](https://flexboxfroggy.com/)可以帮助你轻松的实践Flexbox的各项特性。


Flex 专题 01 —— 一维布局模型 Flex


git是分布式版本管理工具，它没有中央仓库。但多人协作时，我们依然需要一个集散地，让协作成员之间统一往集散地推送和拉取更新。否则，点对点的沟通，效率会很低。

所以就引出了git中远端仓库的概念。

## 概念

我们之前所有的操作都是在本地仓库完成的，和本地仓库对应的是远端仓库。那么本地有若干分支，远端仓库是不是也有对应的若干分支呢？

当然。

我们探讨一个问题，在离线状态下，git是不是无从知道远端仓库的任何状态？

我让网络下线，查询从github克隆下来的本地仓库的状态，结果它告诉我本地仓库的master分支是`up to date with 'origin/master'`。

```
$ git status

On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
```

实际上，git的分支有三种：

- 本地分支，我们可以通过`<branch>`写法访问它。
- 远端分支，我们可以通过`<remote branch>`写法访问它。
- 远端分支引用，我们可以通过`<remote/branch>`写法访问它。实际上它也是本地分支，只不过我们无法操作它，只有git的网络操作才可以更新它。离线状态下，git给的状态就是本地分支和远端分支引用的比较结果。

> git官方把我所说的`远端分支引用`称为`远端分支`。知道谁是谁就行了，名字不重要🤔
>
> 我是马蹄疾

我们看一下本地的远端分支引用。

```
.git/
.git/refs/
.git/refs/remotes/
.git/refs/remotes/origin/
.git/refs/remotes/origin/HEAD
.git/refs/remotes/origin/master
```

默认的远端仓库名就叫`origin`。它也有master分支指针，也有HEAD指针。

## 拉取

如果远端仓库有新的提交或者新的分支，我们需要运行`git fetch`命令来拉取更新。

```
$ git fetch

remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:veedrin/git
   3893459..0f80eeb  master     -> origin/master
```

这个命令是`git fetch origin`的缩写。因为`origin`是远端仓库的默认名称，所以可以省略。如果有手动添加的远端仓库，那就必须指定远端仓库的名称了。

这个命令做了什么呢？

它会把新的提交和新的分支拉取到本地，然后更新本地的远端分支引用到最新的提交。

`git fetch`仅仅是将远端的更新拉取下来，同步本地的远端分支引用，不会对本地分支有任何影响。我们需要手动执行合并操作才能更新本地分支。

```
$ git merge origin/master

On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
```

当然，有一个更简单的操作。

```
$ git pull

remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
Unpacking objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
From github.com:veedrin/git
   4fbd1d4..d9785d7  master     -> origin/master
Updating 4fbd1d4..d9785d7
Fast-forward
 README.md | 2 ++
 1 file changed, 2 insertions(+)
```

`git pull`就是`git fetch`和`git merge`的一键操作。

## 推送

推送到远端的命令是`git push <remote-name> <remote-branch-name>`。

```
$ git push origin master

Counting objects: 3, done.
Writing objects: 100% (3/3), 261 bytes | 261.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:veedrin/git.git
   3eaa1ae..2bd3c9d  master -> master
```

如果当前分支对远端分支设置了追踪的话，也可以省略分支名。

```
$ git push

Counting objects: 3, done.
Writing objects: 100% (3/3), 261 bytes | 261.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:veedrin/git.git
   3eaa1ae..2bd3c9d  master -> master
```

有时候本地分支和远端分支同时有新的提交，直接`push`是不行的。

```
$ git push

To github.com:veedrin/git.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'git@github.com:veedrin/git.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
```

有两种方式解决。

第一是先把远端的更新拉下来，有冲突则解决冲突，没冲突则再推送。

第二是强推。有时候我们就是想覆盖远端对吧，也不是不行，但是必须十分谨慎。而且不要在公共分支上强制推送。

```
$ git push -f

Counting objects: 24, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (24/24), 3.72 KiB | 1.24 MiB/s, done.
Total 24 (delta 0), reused 3 (delta 0)
To github.com:veedrin/git.git
 + 54d741b...2db10e0 master -> master (forced update)
```

实际开发时我们会建很多特性分支，推送到远端，通过测试后再合入主分支。使用`git push <remote-name> <remote-branch-name>`每次都要指定远端分支名，如果会有多次推送，我们可以在推送时设置本地分支追踪远端分支，这样下次就可以直接推送了。

也可以简写成`git push -u <remote-name> <remote-branch-name>`。

```
$ git push --set-upstream origin dev

Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 255 bytes | 255.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: 
remote: Create a pull request for 'dev' on GitHub by visiting:
remote:      https://github.com/veedrin/git/pull/new/dev
remote: 
To github.com:veedrin/git.git
 * [new branch]      dev -> dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.
```

然后我们在`.git/config`文件中能看到多了一条配置。

```
[branch "dev"]
	remote = origin
	merge = refs/heads/dev
```

## 查看

查看远端仓库的命令是`git remote`。

```
$ git remote

origin
```

加`-v`参数可以查看更为详细的信息，`-v`是`--verbose`的缩写。

```
$ git remote -v

origin	git@github.com:veedrin/git.git (fetch)
origin	git@github.com:veedrin/git.git (push)
```

查看某个远端仓库的信息，可以使用命令`git remote show <remote-name>`。

```
$ git remote show origin

* remote origin
  Fetch URL: git@github.com:veedrin/git-1.git
  Push  URL: git@github.com:veedrin/git-1.git
  HEAD branch: master
  Remote branches:
    dev    tracked
    master tracked
  Local branches configured for 'git pull':
    dev    merges with remote dev
    master merges with remote master
  Local refs configured for 'git push':
    master pushes to master (up to date)
```

## 添加

添加新的远端仓库，使用`git remote add <shortname> <url>`命令。

```
$ git remote add horseshoe https://github.com/veedrin/horseshoe
```

然后本地就多了一个远端仓库。

```
$ git remote

horseshoe
origin
```

除了添加远端仓库，我们还可以添加本地分支对远端分支的追踪。

```
$ git checkout -b dev origin/dev

Branch 'dev' set up to track remote branch 'dev' from 'origin'.
Switched to a new branch 'dev'
```

创建dev分支的同时，也设置了对远端分支dev的追踪，这样下次推送的时候就不需要指定了。

当然，远端分支引用必须得存在才行。

```
$ git checkout -b dev origin/dev

fatal: 'origin/dev' is not a commit and a branch 'dev' cannot be created from it
```

git也提供了快捷方式。

```
$ git checkout --track origin/dev

Branch 'dev' set up to track remote branch 'dev' from 'origin'.
Switched to a new branch 'dev'
```

## 重命名

有时候你想修改远端仓库的简写名。比如你将女朋友的名字命名为远端仓库的简写名，然后你们分手了。这真是一个令人悲伤(欣喜)的故事。

```
$ git remote rename nvpengyou gaoyuanyuan
```

查看远端仓库列表。

```
$ git remote

gaoyuanyuan
origin
```

## 删除

一般来说，一个git项目有一个远端仓库就行了，其余的大多是临时性的。所以总有一天要删除它。

```
$ git remote rm horseshoe
```

查看远端仓库列表。

```
$ git remote

origin
```

Git 专题 13 —— remote


git是一个版本管理工具，但在众多版本中，肯定有一些版本是比较重要的，这时候我们希望给这些特定的版本打上标签。比如发布一年以后，程序的各项功能都趋于稳定，可以在圣诞节发布`v1.0`版本。这个`v1.0`在git中就可以通过标签实现。

而git标签又分为两种，轻量级标签和含附注标签。

轻量级标签和分支的表现形式是一样的，仅仅是一个指向commit的指针而已。只不过它不能切换，一旦贴上就无法再挪动了。

含附注标签才是我们理解的那种标签，它是一个独立的git对象。包含标签的名字，电子邮件地址和日期，以及标签说明。

## 创建

创建轻量级标签的命令很简单，运行`git tag <tag name>`。

```
$ git tag v0.3
```

在`.git`目录中就多了一个指针文件。

```
.git/refs/tags/v0.3
```

创建含附注标签要加一个参数`-a`，它是`--annotated`的缩写。

```
$ git tag -a v1.0
```

和`git commit`一样，如果不加`-m`参数，则会弹出默认或者自定义的编辑器，要求你写标签说明。

不写呢？

```
fatal: no tag message?
```

创建完含附注标签后，`.git`目录会多出两个文件。

```
.git/refs/tags/v0.3
```

```
.git/objects/80/e79e91ce192e22a9fd860182da6649c4614ba1
```

含附注标签不仅会创建一个指针，还会创建一个tag对象。

我们了解过git有四种对象类型，tag类型是我们认识的最后一种。

我们看看该对象的类型。

```
$ git cat-file -t 80e79e9

tag
```

再来看看该对象的内容。

```
$ git cat-file -p 80e79e9

object 359fd95229532cd352aec43aada8e6cea68d87a9
type commit
tag v1.0
tagger veedrin <veedrin@qq.com> 1545878480 +0800
版本 v1.0
```

它关联的是一个commit对象，包含标签的名称，打标签的人，打标签的时间以及标签说明。

我可不可以给历史commit打标签呢？当然可以。

```
$ git tag -a v1.0 36ff0f5
```

只需在后面加上commit的校验和。

## 查看

查看当前git项目的标签列表，运行`git tag`命令不带任何参数即可。

```
$ git tag

v0.3
v1.0
```

注意git标签是按字母顺序排列的，而不是按时间顺序排列。

而且我并没有找到分别查看轻量级标签和含附注标签的方法。

查看标签详情可以使用`git show <tag name>`。

```
$ git show v0.3

commit 36ff0f58c8e6b6a441733e909dc95a6136a4f91b (tag: v0.3)
Author: veedrin <veedrin@qq.com>
Date:   Thu Dec 27 11:08:09 2018 +0800
    add a.md
diff --git a/a.md b/a.md
new file mode 100644
index 0000000..e69de29
```

```
$ git show v1.0

tag v1.0
Tagger: veedrin <veedrin@qq.com>
Date:   Thu Dec 27 11:08:39 2018 +0800
版本 v1.0
commit 6dfdb65ce65b782a6cb57566bcc1141923059d2b (HEAD -> master, tag: v1.0)
Author: veedrin <veedrin@qq.com>
Date:   Thu Dec 27 11:08:33 2018 +0800
    add b.md
diff --git a/b.md b/b.md
new file mode 100644
index 0000000..e69de29
```

## 删除

虽然git标签不能移动对吧，但我们可以删除它呀。

```
$ git tag -d v0.3

Deleted tag 'v0.3' (was 36ff0f5)
```

如果标签已经推送到了远端，也是可以删除的。

```
$ git push origin -d v0.3

To github.com:veedrin/git.git
 - [deleted]         v0.3
```

## 推送

默认情况下，`git push`推送到远端仓库并不会将标签也推送上去。如果想将标签推送到远端与别人共享，我们得显式的运行命令`git push origin <tag name>`。

```
$ git push origin v1.0

Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 160.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To github.com:veedrin/git.git
 * [new tag]         v1.0 -> v1.0
```

这里并不区分轻量级标签和含附注标签。

一次性将本地标签推送到远端仓库也是可以的。

```
$ git push origin --tags
```

Git 专题 12 —— tag


程序遇到bug的时候，我们需要快速定位。

定位有两种，第一种是定位bug在哪个提交上，第二种是定位特定文件的某一行是谁最近提交的。

## bisect

有时候我们发现程序有bug，但是回退几个版本都不解决问题。说明这个bug是一次很老的提交导致的，也不知道当时怎么就没察觉。

那怎么办呢？继续一个一个版本的回退？

估计`Linus Torvalds`会鄙视你吧。

为了专注于工作，不分心来鄙视你，`Linus Torvalds`在git中内置了一套定位bug的命令。

大家都玩过猜数字游戏吧。主持人悄悄写下一个数，给大家一个数字区间，然后大家轮流开始切割，谁切到主持人写的那个数就要自罚三杯了。

对，这就是二分法。git利用二分法定位bug的命令是`git bisect`。

#### 使用

假设目前的git项目历史是这样的。

```
C0 -- C1 -- C2 -- C3 -- C4 -- C5 -- C6 -- C7 -- C8 -- C9(HEAD -> master)
```

这里面有一次commit藏了一个bug，但幸运的是，你不知道是哪一次。

运行`git bisect start`命令，后跟你要定位的区间中最新的commit和最老的commit。

```
$ git bisect start HEAD C0

Bisecting: 4 revisions left to test after this (roughly 2 steps)
[ee27077fdfc6c0c9281c1b7f6957ea2b59a461dd] C4
```

然后你就发现HEAD指针自动的指向了`C4`commit。如果范围是奇数位，那取中间就行了，如果范围是偶数位，则取中间更偏老的那个commit，就比如这里的`C4`commit。

```
$ git bisect good

Bisecting: 2 revisions left to test after this (roughly 1 step)
[97cc0e879dc09796bd56cfd7c3a54deb41e447f6] C6
```

HEAD指针指向`C4`commit后，你应该运行一下程序，如果没问题，那说明有bug的提交在它之后。我们只需要告诉git当前commit以及更老的commit都是好的。

然后HEAD指针就自动指向`C6`commit。

继续在`C6`commit运行程序，结果复现了bug。说明问题就出在`C6`commit和`C4`commit之间。

```
$ git bisect bad

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[a7e09bd3eab7d1e824c0338233f358cafa682af0] C5
```

将`C6`commit标记为`bad`之后，HEAD指针自动指向`C5`commit。再次运行程序，依然能复现bug。话不多说，标记`C5`commit为`bad`。

```
$ git bisect bad

a7e09bd3eab7d1e824c0338233f358cafa682af0 is the first bad commit
```

因为`C4`commit和`C5`commit之间已经不需要二分了，git会告诉你，`C5`commit是你标记为`bad`的最早的commit。问题就应该出在`C5`commit上。

```
git bisect reset

Previous HEAD position was a7e09bd... C5
Switched to branch 'master'
```

既然找到问题了，那就可以退出`git bisect`工具了。

另外，`git bisect old`和`git bisect good`的效果相同，`git bisect new`和`git bisect bad`的效果相同，这是因为git考虑到，有时候开发者并不是想定位bug，只是想定位某个commit，这时候用`good bad`就会有点别扭。

#### 后悔

`git bisect`确实很强大，但如果我已经`bisect`若干次，结果不小心把一个`good`commit标记为`bad`，或者相反，难道我要`reset`重来么？

`git bisect`还有一个`log`命令，我们只需要保存`bisect`日志到一个文件，然后擦除文件中标记错误的日志，然后按新的日志重新开始`bisect`就好了。

```
git bisect log > log.txt
```

该命令的作用是将日志保存到`log.txt`文件中。

看看`log.txt`文件中的内容。

```
# bad: [4d5e75c7a9e6e65a168d6a2663e95b19da1e2b21] C9
# good: [c2fa7ca426cac9990ba27466520677bf1780af97] add a.md
git bisect start 'HEAD' 'c2fa7ca426cac9990ba27466520677bf1780af97'
# good: [ee27077fdfc6c0c9281c1b7f6957ea2b59a461dd] C4
git bisect good ee27077fdfc6c0c9281c1b7f6957ea2b59a461dd
# good: [97cc0e879dc09796bd56cfd7c3a54deb41e447f6] C6
git bisect good 97cc0e879dc09796bd56cfd7c3a54deb41e447f6
```

将标记错误的内容去掉。

```
# bad: [4d5e75c7a9e6e65a168d6a2663e95b19da1e2b21] C9
# good: [c2fa7ca426cac9990ba27466520677bf1780af97] add a.md
git bisect start 'HEAD' 'c2fa7ca426cac9990ba27466520677bf1780af97'
# good: [ee27077fdfc6c0c9281c1b7f6957ea2b59a461dd] C4
git bisect good ee27077fdfc6c0c9281c1b7f6957ea2b59a461dd
```

然后运行`git bisect replay log.txt`命令。

```
$ git bisect replay log.txt

Previous HEAD position was ad95ae3... C8
Switched to branch 'master'
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[ee27077fdfc6c0c9281c1b7f6957ea2b59a461dd] C4
Bisecting: 2 revisions left to test after this (roughly 1 step)
[97cc0e879dc09796bd56cfd7c3a54deb41e447f6] C6
```

git会根据log从头开始重新`bisect`，错误的标记就被擦除了。

然后就是重新做人啦。

## blame

一个充分协作的项目，每个文件可能都被多个人改动过。当出现问题的时候，大家希望快速的知道，某个文件的某一行是谁最后改动的，以便厘清责任。

`git blame`就是这样一个命令。`blame`翻译成中文是`归咎于`，这个命令就是用来甩锅的。

`git blame`只能作用于单个文件。

```
$ git blame a.md

705d9622 (veedrin 2018-12-25 10:09:04 +0800 1) 第一行
74eff2ee (abby 2018-12-25 10:16:44 +0800 2) 第二行
a65b29bd (bob 2018-12-25 10:17:02 +0800 3) 第三行
ee27077f (veedrin 2018-12-25 10:19:05 +0800 4) 第四行
a7e09bd3 (veedrin 2018-12-25 10:19:19 +0800 5) 第五行
97cc0e87 (veedrin 2018-12-25 10:21:55 +0800 6) 第六行
67029a81 (veedrin 2018-12-25 10:22:15 +0800 7) 第七行
ad95ae3f (zhangsan 2018-12-25 10:23:20 +0800 8) 第八行
4d5e75c7 (lisi 2018-12-25 10:23:37 +0800 9) 第九行
```

它会把每一行的修改者信息都列出来。

第一部分是commit哈希值，表示这一行的最近一次修改属于该次提交。

第二部分是作者以及修改时间。

第三部分是行的内容。

如果文件太长，我们可以截取部分行。

```
$ git blame -L 1,5 a.md

705d9622 (veedrin 2018-12-25 10:09:04 +0800 1) 第一行
74eff2ee (abby 2018-12-25 10:16:44 +0800 2) 第二行
a65b29bd (bob 2018-12-25 10:17:02 +0800 3) 第三行
ee27077f (veedrin 2018-12-25 10:19:05 +0800 4) 第四行
a7e09bd3 (veedrin 2018-12-25 10:19:19 +0800 5) 第五行
```

或者这样写。

```
$ git blame -L 1,+4 a.md

705d9622 (veedrin 2018-12-25 10:09:04 +0800 1) 第一行
74eff2ee (abby 2018-12-25 10:16:44 +0800 2) 第二行
a65b29bd (bob 2018-12-25 10:17:02 +0800 3) 第三行
ee27077f (veedrin 2018-12-25 10:19:05 +0800 4) 第四行
```

但是结果不是你预期的那样是吧。`1,+4`的确切意思是从1开始，显示4行。

如果有人重名，可以显示邮箱来区分。添加参数`-e`或者`--show-email`即可。

```
$ git blame -e a.md

705d9622 (veedrin@qq.com 2018-12-25 10:09:04 +0800 1) 第一行
74eff2ee (abby@qq.com 2018-12-25 10:16:44 +0800 2) 第二行
a65b29bd (bob@qq.com 2018-12-25 10:17:02 +0800 3) 第三行
ee27077f (veedrin@qq.com 2018-12-25 10:19:05 +0800 4) 第四行
a7e09bd3 (veedrin@qq.com 2018-12-25 10:19:19 +0800 5) 第五行
97cc0e87 (veedrin@qq.com 2018-12-25 10:21:55 +0800 6) 第六行
67029a81 (veedrin@qq.com 2018-12-25 10:22:15 +0800 7) 第七行
ad95ae3f (zhangsan@qq.com 2018-12-25 10:23:20 +0800 8) 第八行
4d5e75c7 (lisi@qq.com 2018-12-25 10:23:37 +0800 9) 第九行
```

Git 专题 11 —— position


有四个git命令可以用来查看git仓库相关信息。

## status

`git status`命令的作用是同时展示工作区和暂存区的diff、暂存区和当前版本的diff、以及没有被git追踪的文件。

```
$ git status

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   a.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   b.md
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	c.md
```

这个命令应该是最常用的git命令之一了，每次提交之前都要看一下。

`git status -v`命令相当于`git status`命令和`git diff --staged`之和。

```
$ git status -v

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   a.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   b.md
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	c.md
diff --git a/a.md b/a.md
index 5646a65..4c479de 100644
--- a/a.md
+++ b/a.md
@@ -1 +1 @@
-apple
+banana
```

`git status -vv`命令相当于`git status`命令和`git diff`之和。

```
$ git status -vv

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   a.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   b.md
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	c.md
Changes to be committed:
diff --git c/a.md i/a.md
index 5646a65..4c479de 100644
--- c/a.md
+++ i/a.md
@@ -1 +1 @@
-apple
+banana
--------------------------------------------------
Changes not staged for commit:
diff --git i/b.md w/b.md
index e69de29..637a09b 100644
--- i/b.md
+++ w/b.md
@@ -0,0 +1 @@
+## git is awesome
```

还有一个`-s`参数，给出的结果很有意思。

```
$ git status -s

M  a.md
 M b.md
?? c.md
```

注意看，前面的字母位置是不一样的。

第一个位置是该文件在暂存区的状态，第二个位置是该文件在工作区的状态。比如，以下信息显示`a.md`文件在暂存区有改动待提交，在工作区也有改动待暂存。

```
MM a.md
```

缩写的状态码主要有这么几种：

| 状态码 | 含义            |
| ------ | --------------- |
| M      | 文件内容有改动  |
| A      | 文件被添加      |
| D      | 文件被删除      |
| R      | 文件被重命名    |
| C      | 文件被复制      |
| U      | 文件冲突未解决  |
| ?      | 文件未被git追踪 |
| !      | 文件被git忽略   |

> `?`和`!`所代表的状态因为没有进入git版本系统，所以任何时候两个位置都是一样的。就像`??`或者`!!`这样。

## show

`git show`命令`show`的是什么呢？git对象。

```
$ git show

commit 2bd3c9d7de54cec10f0896db9af04c90a41a8160
Author: veedrin <veedrin@qq.com>
Date:   Fri Dec 28 11:23:27 2018 +0800
    update
diff --git a/README.md b/README.md
index e8ab145..75625ce 100644
--- a/README.md
+++ b/README.md
@@ -5,3 +5,5 @@ one
 two
 three
+
+four
```

`git show`相当于`git show HEAD`，显示当前HEAD指向的commit对象的信息。

当然，你也可以查看某个git对象的信息，后面跟上git对象的校验和就行。

```
$ git show 38728d8

tree 38728d8
README.md
```

## diff

`git diff`命令可以显示两个主体之间的差异。

#### 工作区与暂存区的差异

单纯的`git diff`命令显示工作区与暂存区之间的差异。

```
$ git diff

diff --git a/a.md b/a.md
index e69de29..5646a65 100644
--- a/a.md
+++ b/a.md
@@ -0,0 +1 @@
+## git is awesome
```

因为是两个主体之间的比较，git永远将两个主体分别命名为`a`和`b`。

也可以只查看某个文件的diff。当然这里依然是工作区与暂存区之间的差异。

```
$ git diff a.md
```

#### 暂存区与当前commit的差异

`git diff --staged`命令显示暂存区与当前commit的差异。

`git diff --cached`也可以达到相同的效果，它比较老，不如`--staged`语义化。

```
$ git diff --staged

diff --git a/b.md b/b.md
index e69de29..4c479de 100644
--- a/b.md
+++ b/b.md
@@ -0,0 +1 @@
+apple
```

同样，显示某个文件暂存区与当前commit的差异。

```
$ git diff --staged a.md
```

#### 两个commit之间的差异

我们还可以用`git diff`查看两个commit之间的差异。

```
$ git diff C1 C2

diff --git a/a.md b/a.md
index e69de29..5646a65 100644
--- a/a.md
+++ b/a.md
@@ -0,0 +1 @@
+## git is awesome
diff --git a/b.md b/b.md
new file mode 100644
index 0000000..e69de29
```

注意先后顺序很重要，假如我改一下顺序。

```
$ git diff C2 C1

diff --git a/a.md b/a.md
index 5646a65..e69de29 100644
--- a/a.md
+++ b/a.md
@@ -1 +0,0 @@
-## git is awesome
diff --git a/b.md b/b.md
deleted file mode 100644
index e69de29..0000000
```

比较两个commit之间某个文件的差异。

```
$ git diff C1:a.md C2:a.md

diff --git a/a.md b/a.md
index e69de29..5646a65 100644
--- a/a.md
+++ b/a.md
@@ -0,0 +1 @@
+## git is awesome
```

## log

`git log`命令显示提交历史。

```
$ git log

commit 7e2514419ec0f75d1557d3d8165a7e7969f08349
Author: veedrin <veedrin@qq.com>
Date:   Sat Dec 29 11:56:53 2018 +0800
    c.md
commit 4d346773212b208380f71885979f93da65f07ea6
Author: veedrin <veedrin@qq.com>
Date:   Sat Dec 29 11:56:41 2018 +0800
    b.md
commit cde34665b49033d7b8aed3a334c3e2db2200b4dd
Author: veedrin <veedrin@qq.com>
Date:   Sat Dec 29 11:54:59 2018 +0800
    a.md
```

如果要查看每个commit具体的改动，添加`-p`参数，它是`--patch`的缩写。

```
$ git log -p

commit 7e2514419ec0f75d1557d3d8165a7e7969f08349
Author: veedrin <veedrin@qq.com>
Date:   Sat Dec 29 11:56:53 2018 +0800
    c.md
diff --git a/c.md b/c.md
new file mode 100644
index 0000000..e69de29
commit 4d346773212b208380f71885979f93da65f07ea6
Author: veedrin <veedrin@qq.com>
Date:   Sat Dec 29 11:56:41 2018 +0800
    b.md
diff --git a/b.md b/b.md
new file mode 100644
index 0000000..e69de29
commit cde34665b49033d7b8aed3a334c3e2db2200b4dd
Author: veedrin <veedrin@qq.com>
Date:   Sat Dec 29 11:54:59 2018 +0800
    a.md
diff --git a/a.md b/a.md
new file mode 100644
index 0000000..e69de29
```

你还可以控制显示最近几条。

```
$ git log -p -1

commit 7e2514419ec0f75d1557d3d8165a7e7969f08349
Author: veedrin <veedrin@qq.com>
Date:   Sat Dec 29 11:56:53 2018 +0800
    c.md
diff --git a/c.md b/c.md
new file mode 100644
index 0000000..e69de29
```

`-p`有点过于冗余，只是想查看文件修改的统计信息的话，可以使用`--stat`参数。

```
$ git log --stat

commit 7e2514419ec0f75d1557d3d8165a7e7969f08349
Author: veedrin <veedrin@qq.com>
Date:   Sat Dec 29 11:56:53 2018 +0800
    c.md
 c.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
commit 4d346773212b208380f71885979f93da65f07ea6
Author: veedrin <veedrin@qq.com>
Date:   Sat Dec 29 11:56:41 2018 +0800
    b.md
 b.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
commit cde34665b49033d7b8aed3a334c3e2db2200b4dd
Author: veedrin <veedrin@qq.com>
Date:   Sat Dec 29 11:54:59 2018 +0800
    a.md
 a.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
```

还觉得冗余？只想看提交说明，有一个`--oneline`可以帮到你。

```
$ git log --oneline

4ad50f6 (HEAD -> master) 添加c.md文件
4d34677 添加b.md文件
cde3466 添加a.md文件
```

想在命令行工具看git提交历史的树形图表，用`--graph`参数。

```
$ git log --graph

* commit 7e2514419ec0f75d1557d3d8165a7e7969f08349 (HEAD -> master)
| Author: veedrin <veedrin@qq.com>
| Date:   Sat Dec 29 11:56:53 2018 +0800
|     c.md
* commit 4d346773212b208380f71885979f93da65f07ea6
| Author: veedrin <veedrin@qq.com>
| Date:   Sat Dec 29 11:56:41 2018 +0800
|     b.md
* commit cde34665b49033d7b8aed3a334c3e2db2200b4dd
  Author: veedrin <veedrin@qq.com>
  Date:   Sat Dec 29 11:54:59 2018 +0800
      a.md
```

我知道你们肯定又觉得冗余，`--graph`和`--oneline`食用更佳哟。

```
$ git log --graph --oneline

* 7e25144 (HEAD -> master) c.md
* 4d34677 b.md
* cde3466 a.md
```

Git 专题 10 —— view


你在一个分支上开展了一半的工作，突然有一件急事要你去处理。这时候你得切换到一个新的分支，可是手头上的工作你又不想立即提交。

这种场景就需要用到git的储藏功能。

## 储藏

想要储藏手头的工作，只需运行`git stash`命令。

```
$ git status

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   a.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   b.md
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	c.md
```

```
$ git stash

Saved working directory and index state WIP on master: 974a2f2 update
```

`WIP`是`work in progress`的缩写，指的是进行中的工作。

```
$ git status

On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	c.md
nothing added to commit but untracked files present (use "git add" to track)
```

可以看到，除了未被git跟踪的文件之外，工作区和暂存区的内容都会被储藏起来。现在你可以切换到其他分支进行下一步工作了。

## 查看

我们看一下储藏列表。

```
$ git stash list

stash@{0}: WIP on master: 974a2f2 apple
stash@{1}: WIP on master: c27b351 banana
```

## 恢复

等我们完成其他工作，肯定要回到这里，继续进行中断的任务。

```
$ git stash apply

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   a.md
	modified:   b.md
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	c.md
no changes added to commit (use "git add" and/or "git commit -a")
```

诶，等等。怎么`a.md`的变更也跑到工作区了？是的，`git stash`默认会将暂存区和工作区的储藏全部恢复到工作区。如果我就是想原样恢复呢？

```
$ git stash apply --index

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   a.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   b.md
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	c.md
```

加一个参数`--index`就会让工作区的归工作区，让暂存区的归暂存区。

还有一点需要注意，恢复储藏的操作可以应用在任何分支，它也不关心即将恢复储藏的分支上，工作区和暂存区是否干净。如果有冲突，自行解决就是了。

我们浏览过储藏列表，说明`git stash apply`仅仅是恢复了最新的那一次储藏。

```
$ git stash apply stash@{1}
```

指定储藏的名字，我们就可以恢复列表中的任意储藏了。

这个时候我们再看一下储藏列表。

```
$ git stash list

stash@{0}: WIP on master: 974a2f2 apple
stash@{1}: WIP on master: c27b351 banana
```

诶，发现还是两条。我不是已经恢复了一条么？

`apply`这个词很巧妙，它只是应用，它可不会清理。

## 清理

想要清理储藏列表，咱们得显式的运行`git stash drop`命令。

```
$ git stash drop stash@{1}
```

```
$ git stash list

stash@{0}: WIP on master: 974a2f2 apple
```

现在就真的没有了。希望你没有喝酒🙃。

git还给我们提供了一个快捷操作，运行`git stash pop`命令，同时恢复储藏和清理储藏。

```
$ git stash pop
```

Git 专题 09 —— stash


有时候我们想撤回一个commit，但是这个commit已经在公共的分支上。如果直接修改分支历史，可能会引起一些不必要的混乱。这个时候，`git revert`命令就派上用场了。

`revert`翻译成中文是`还原`。我觉得称它为对冲更合理。对冲指的是同时进行两笔行情相关、方向相反、数量相当、盈亏相抵的交易，这么理解`git revert`命令一针见血。

因为它的作用就是生成一个新的、完全相反的commit。

## 命令

`git revert`后跟你想要对冲的commit即可。

```
$ git revert HEAD

Revert "add c.md"
This reverts commit 8a23dad059b60ba847a621b6058fb32fa531b20a.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#	deleted:    c.md
```

git会弹出默认或者自定义的编辑器要求你输入commit信息。然后一个新的commit就生成了。

```
[master a8c4205] Revert "add c.md"
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 c.md
```

可以看到，原本我添加了一个文件`a.md`，`revert`操作就会执行删除命令。在工作目录看起来就像添加文件操作被撤销了一样，其实是被对冲了。

它不会改变commit历史，只会增加一个新的对冲commit。这是它最大的优点。

## 冲突

反向操作也会有冲突？你逗我的吧。

如果你操作的是最新的commit，那当然不会有冲突了。

那要操作的是以前的commit呢？

```
C0 -- C1 -- C2(HEAD -> master)
```

比如`a.md`在`C0`内容为空，`C1`修改文件内容为`apple`，`C2`修改文件内容为`banana`。这时候你想撤销`C1`的修改。

```
$ git revert HEAD~

error: could not revert 483b537... apple
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
```

我们看一下文件内容。

```
<<<<<<< HEAD
banana
=======
>>>>>>> parent of 483b537... apple
```

手动解决冲突，执行`git add`命令然后执行`git revert --continue`命令完成对冲操作。

取消`revert`操作只需要执行`git revert --abort`即可。

Git 专题 08 —— revert


`git checkout`命令可以在版本之间随意切换，它的本质是移动HEAD指针。

那git有没有办法移动分支指针呢？

当然有，这就是`git reset`命令。

## 底层

`git reset`命令与`git checkout`命令的区别在于，它会把HEAD指针和分支指针一起移动，如果HEAD指针指向的是一个分支指针的话。

我们前面说过使用`git checkout`命令从有分支指向的commit切换到一个没有分支指向的commit上，这个时候的HEAD指针被称为`detached HEAD`。这是非常危险的。

```
C0 -- C1 -- C2(HEAD -> master)
```

```
$ git checkout C1
```

```
C0 -- C1(HEAD) -- C2(master)
```

但是`git reset`命令没有这个问题，因为它会把当前的分支指针也带过去。

```
C0 -- C1 -- C2(HEAD -> master)
```

```
$ git reset C1
```

```
C0 -- C1(HEAD -> master) -- C2
```

这就是`重置`的含义所在。它可以重置分支。

看另一种情况。如果是从一个没有分支指向的commit切换到另一个没有分支指向的commit上，那它们就是两个韩国妹子，傻傻分不清楚了。

这是`git checkout`命令的效果。

```
C0 -- C1 -- C2(HEAD) -- C3(master)
```

```
$ git checkout C1
```

```
C0 -- C1(HEAD) -- C2 -- C3(master)
```

这是`git reset`命令的效果。

```
C0 -- C1 -- C2(HEAD) -- C3(master)
```

```
$ git reset C1
```

```
C0 -- C1(HEAD) -- C2 -- C3(master)
```

## 同时重置暂存区和工作区的改动

当你在 `git reset` 命令后面加 `--hard` 参数时，暂存区和工作区的内容都会重置为重置后的commit内容。也就是说暂存区和工作区的改动都会清空，相当于撤销暂存区和工作区的改动。

而且是没有确认操作的哟。

```
$ git status

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   a.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   a.md
```

```
$ git reset --hard HEAD^

HEAD is now at 58b0040 commit for nothing
```

```
$ git status

On branch master
nothing to commit, working tree clean
```

## 仅重置暂存区的改动

 `git reset` 命令后面加 `--mixed` 参数，或者不加参数，因为`--mixed`参数是默认值，暂存区的内容会重置为重置后的commit内容，工作区的改动不会清空，相当于撤销暂存区的改动。

同样也是没有确认操作的哟。

```
$ git status

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   a.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   a.md
```

```
$ git reset HEAD^

Unstaged changes after reset:
M	a.md
```

```
$ git status

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   a.md
no changes added to commit (use "git add" and/or "git commit -a")
```

打个趣，如果`git reset`命令什么都不加会怎样呢？

你可以脑补一下，`git reset`命令不加参数默认就是`--mixed`，不加操作对象默认就是`HEAD`，所以单纯的`git reset`命令相当于`git reset --mixed HEAD`命令。

那这又意味着什么呢？

这意味着从当前commit重置到当前commit，没有变化对吧？但是`--mixed`参数会撤销暂存区的改动对不对，这就是它的效果。

## 同时保留暂存区和工作区的改动

如果 `git reset` 命令后面加 `--soft` 参数，钢铁直男的温柔，你懂的。仅仅是重置commit而已，暂存区和工作区的改动都会保留下来。

更温柔的是，重置前的commit内容与重置后的commit内容的diff也会放入暂存区。

```
$ git status

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   a.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   a.md
```

```
$ git diff --staged

diff --git a/a.md b/a.md
index 4a77268..fde8dcd 100644
--- a/a.md
+++ b/a.md
@@ -1,2 +1,3 @@
 apple
 banana
+cherry
```

```
$ git reset --soft HEAD^
```

```
$ git status

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   a.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   a.md
```

```
$ git diff --staged

diff --git a/a.md b/a.md
index 4a77268..fde8dcd 100644
--- a/a.md
+++ b/a.md
@@ -1 +1,3 @@
 apple
+banana
+cherry
```

`banana`就是重置前的commit内容与重置后的commit内容的diff，可以看到，它已经在暂存区了。

## 文件暂存区内容撤回工作区

`git reset`命令后面也可以跟文件名，它的作用是将暂存区的内容重置为工作区的内容，是`git add -- <file>`的反向操作。

`git reset -- <file>`命令是`git reset HEAD --mixed -- <file>`的简写。在操作文件时，参数只有默认的`--mixed`一种。

它并不会撤销工作区原有的改动。

```
$ git status

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   a.md
```

```
$ git reset -- a.md

Unstaged changes after reset:
M	a.md
```

```
$ git status

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   a.md
no changes added to commit (use "git add" and/or "git commit -a")
```

`git checkout`命令后面也可以跟文件名，它的作用是撤销工作区的改动，需要注意区分。

## 文件若干commit版本撤回工作区

如果`git reset`命令后跟一个commit校验和，它会把该commit与所有后代commit的diff重置到工作区。

意思就是将该文件重置回你指定的commit版本，但是在你指定的commit之后的改动我也给你留着，就放到工作区里吧。

```
$ git diff --staged

# 空
```

```
git reset HEAD~4 -- a.md

Unstaged changes after reset:
M	a.md
```

```
$ git diff --staged

diff --git a/a.md b/a.md
index 6f195b4..72943a1 100644
--- a/a.md
+++ b/a.md
@@ -1,5 +1 @@
 aaa
-bbb
-ccc
-ddd
-eee
```

`git diff --staged`命令比较工作区和暂存区的内容。可以看到初始工作区和暂存区是一致的，重置文件到4个版本之前，发现工作区比暂存区多了很多改动，这些都是指定commit之后的提交被重置到工作区了。

Git 专题 07 —— reset


`git merge`命令会生成一个新的合并commit。如果你有强迫症，不喜欢这个新的合并commit，git也有更加清爽的方案可以满足你，它就是`git rebase`命令。

git就是哆啦A梦的口袋。

`rebase`翻译过来是`变基`。意思就是将所有要合并进来的commit在新的基础上重新提交一次。

## 基础用法

`git rebase <branch>`会计算当前分支和目标分支的最近共同祖先，然后将最近共同祖先与当前分支之间的所有commit都变基到目标分支上，使得提交历史变成一条直线。

```
C0 -- C1 -- C2 -- C3(master)
       \
        C4 -- C5 -- C6(HEAD -> dev)
```

`merge`与`rebase`后跟的分支名是不一样的。合并是合并进来，变基是变基过去，你们感受一下。

```
$ git rebase master

First, rewinding head to replay your work on top of it...
Applying: C4.md
Applying: C5.md
Applying: C6.md
```

```
C0 -- C1 -- C2 -- C3(master) -- C4' -- C5' -- C6'(HEAD -> dev)
       \
        C4 -- C5 -- C6
```

现在最近共同祖先与当前分支之间的所有commit都被复制到master分支之后，并且将HEAD指针与当前分支指针切换过去。这招移花接木玩的很溜啊，如果你置身其中根本分不出区别。

原来的commit还在吗？还在，如果你记得它的commit校验和，仍然可以切换过去，git会提示你当前处于`detached HEAD`状态下。只不过没有任何分支指针指向它们，它们已经被抛弃了，剩余的时光就是等待git垃圾回收命令清理它们。

好在，还有人记得它们，不是么？

`git rebase`完并没有结束，因为我变基的目标分支是master，而当前分支是dev。我需要切换到master分支上，然后再合并一次。

```
$ git checkout master
```

```
$ git merge dev
```

诶，说来说去，还是要合并啊？

别急，这种合并是`Fast forward`的，并不会生成一个新的合并commit。

如果我要变基的本体分支不是当前分支行不行？也是可以的。

```
$ git rebase master dev
```

你在任何一个分支上，这种写法都可以将dev分支变基到master分支上，变基完成当前分支会变成dev分支。

## 裁剪commit变基

变基有点像基因编辑，git有更精确的工具达到你想要的效果。

> 有了精确的基因编辑技术，妈妈再也不用担心你长的**丑**啦。

```
C0 -- C1 -- C2 -- C3(master)
       \
        C4 -- C5 -- C6(dev)
         \
          C7 -- C8(HEAD -> hotfix)
```

```
$ git rebase --onto master dev hotfix

First, rewinding head to replay your work on top of it...
Applying: C7.md
Applying: C8.md
```

```
C0 -- C1 -- C2 -- C3(master) -- C7' -- C8'(HEAD -> hotfix)
       \
        C4 -- C5 -- C6(dev)
         \
          C7 -- C8
```

`--onto`参数就是那把基因编辑的剪刀。

它会把`hotfix分支`到`hotfix分支与dev分支的最近共同祖先`之间的commit裁剪下来，复制到目标基础点上。注意，所谓的之间指的都是不包括`最近共同祖先commit`的范围，比如这里就不会复制`C4`commit。

```
$ git rebase --onto master dev

First, rewinding head to replay your work on top of it...
Applying: C7.md
Applying: C8.md
```

如果`--onto`后面只写两个分支(或者commit)名，第三个分支(或者commit)默认就是HEAD指针指向的分支(或者commit)。

## 变基冲突解决

变基也会存在冲突的情况，我们看看冲突怎么解决。

```
C0 -- C1 -- C2(HEAD -> master)
       \
        C3 -- C4(dev)
```

```
$ git rebase master dev

First, rewinding head to replay your work on top of it...
Applying: c.md
Applying: a.md add banana
Using index info to reconstruct a base tree...
M	a.md
Falling back to patching base and 3-way merge...
Auto-merging a.md
CONFLICT (content): Merge conflict in a.md
error: Failed to merge in the changes.
Patch failed at 0002 a.md dev
The copy of the patch that failed is found in: .git/rebase-apply/patch
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
```

C2和C4同时修改了`a.md`的某一行，引发冲突。git已经给我们提示了，大体上和`merge`的操作一致。

我们可以手动解决冲突，然后执行`git add`和`git rebase --continue`来完成变基。

如果你不想覆盖目标commit的内容，也可以跳过这个commit，执行`git rebase --skip`。但是注意，这会跳过有冲突的整个commit，而不仅仅是有冲突的部分。

后悔药也是有的，执行`git rebase --abort`，干脆就放弃变基了。

## cherry-pick

`git rebase --onto`命令可以裁剪分支以变基到另一个分支上。但它依然是挑选连续的一段commit，只是允许你指定头和尾罢了。

别急，`git cherry-pick`命令虽然是一个独立的git命令，它的效果却还是变基，而且是commit级别的变基。

`git cherry-pick`命令可以挑选任意commit变基到目标commit上。你负责挑，它负责基。

#### 用法

只需要在`git cherry-pick`命令后跟commit校验和，就可以将它应用到目标commit上。

```
C0 -- C1 -- C2(HEAD -> master)
       \
        C3 -- C4 -- C5(dev)
               \
                C6 -- C7(hotfix)
```

将当前分支切换到master分支。

```
$ git cherry-pick C6

[master dc342e0] c6
 Date: Mon Dec 24 09:13:57 2018 +0800
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 c6.md
```

```
C0 -- C1 -- C2 -- C6'(HEAD -> master)
       \
        C3 -- C4 -- C5(dev)
               \
                C6 -- C7(hotfix)
```

`C6`commit就按原样重新提交到master分支上了。`cherry-pick`并不会修改原有的commit。

同时挑选多个commit也很方便，往后面叠加就行。

```
$ git cherry-pick C4 C7

[master ab1e7c7] c4
 Date: Mon Dec 24 09:12:58 2018 +0800
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 c4.md
[master 161d993] c7
 Date: Mon Dec 24 09:14:12 2018 +0800
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 c7.md
```

```
C0 -- C1 -- C2 -- C4' -- C7'(HEAD -> master)
       \
        C3 -- C4 -- C5(dev)
               \
                C6 -- C7(hotfix)
```

如果这多个commit正好是连续的呢？

```
$ git cherry-pick C3...C7

[master d16c42e] c4
 Date: Mon Dec 24 09:12:58 2018 +0800
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 c4.md
[master d16c42e] c6
 Date: Mon Dec 24 09:13:57 2018 +0800
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 c6.md
[master a4d5976] c7
 Date: Mon Dec 24 09:14:12 2018 +0800
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 c7.md
```

```
C0 -- C1 -- C2 -- C4' -- C6' -- C7'(HEAD -> master)
       \
        C3 -- C4 -- C5(dev)
               \
                C6 -- C7(hotfix)
```

需要注意，git所谓的从某某开始，一般都是不包括某某的，这里也一样。

有没有发现操作连续commit的`git cherry-pick`和`git rebase`的功能已经非常接近了？所以呀，`git cherry-pick`也是变基，只不过一边变基一边喂樱桃给你吃。

#### 冲突

git各种命令解决冲突的方法都大同小异。

```
C0 -- C1(HEAD -> master)
 \
  C2(dev)
```

```
$ git cherry-pick C2

error: could not apply 051c24c... banana
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
```

手动解决冲突，执行`git add`命令然后执行`git cherry-pick --continue`命令。

如果被唬住了想还原，执行`git cherry-pick --abort`即可。

## 变基还是合并

这是一个哲学问题。

有一种观点认为，仓库的commit历史应该记录`实际发生过什么`。所以如果你将一个分支合并进另一个分支，commit历史中就应该有这一次合并的痕迹，因为它是实实在在发生过的。

另一种观点则认为，仓库的commit历史应该记录`项目过程中发生过什么`。合并不是项目开发本身带来的，它是一种额外的操作，会使commit历史变的冗长。

我是一个极简主义者，所以我支持首选变基。

Git 专题 06 —— rebase


可以方便的创建分支是git如此受欢迎的重要原因，利用`git checkout <branch>`也让开发者在分支之间穿梭自如。然而百川终入海，其他分支上完成的工作终究是要合并到主分支上去的。

所以我们来看看git中的合并操作。

首先说明，执行`git merge`命令之前需要一些准备工作。

```
$ git merge dev

error: Your local changes to the following files would be overwritten by merge:
	a.md
Please commit your changes or stash them before you merge.
Aborting
```

合并操作之前必须保证暂存区内没有待提交内容，否则git会阻止合并。这是因为合并之后，git会将合并后的版本覆盖暂存区。所以会有丢失工作成果的危险。

至于工作区有待添加到暂存区的内容，git倒不会阻止你。可能git觉得它不重要吧。

不过最好还是保持一个干净的工作区再执行合并操作。

## 不同分支的合并

不同分支指的是要合并的两个commit在某个祖先commit之后开始分叉。

```
C0 -- C1 -- C2(HEAD -> master)
       \
        C3(dev)
```

`git merge`后跟合并客体，表示要将它合并进来。

```
$ git merge dev
```

进行到这里，如果没有冲突，git会弹出默认或者自定义的编辑器，让你填写commit说明。当然它会给你填写一个默认的commit说明。

```
Merge branch 'dev'

# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
```

为什么要你填写commit说明？因为这种情况的`git merge`实际上会创建一个新的commit对象，记录此次合并的信息，并将当前分支指针移动到它上面来。

```
C0 -- C1 -- C2 -- C4(HEAD -> master)(merge commit)
       \          /
        \        /
          C3(dev)
```

大家常说不同分支的`git merge`操作是一个三方合并，这里的三方指的是`合并主体commit`、`合并客体commit`以及`合并主客体的共同祖先commit`。

所谓的三方和并到底是什么意思呢？

git会提取出`合并主体commit`相对于`合并主客体的共同祖先commit`的diff与`合并客体commit`相对于`合并主客体的共同祖先commit`的diff，再去比较这两份diff有没有修改同一个地方，这里同一个地方的单位是文件的行。如果没有，那就将这两份diff合并生成一个新的commit，当前分支指针向右移。如果有那就要求开发者自行解决。

所以在三方合并中，`合并主客体的共同祖先commit`只是一个参照物。

## 合并主体在合并客体的上游

它指的是开发者当前在一个commit节点上，要将同一个分支上更新的commit节点合并进来。

```
C0 -- C1 -- C2(HEAD -> master) -- C3(dev)
```

这时候会发生什么呢？

这相当于更新当前分支指针，所以只需要将当前分支指针向下游移动，让合并主体与合并客体指向同一个commit即可。这时并不会产生一个新的commit。

用三方合并的概念来理解，`合并主体commit`与`合并主客体的共同祖先commit`是同一个commit，`合并主体commit`相对于`合并主客体的共同祖先commit`的diff为空，`合并客体commit`相对于`合并主客体的共同祖先commit`的diff与空diff合并还是它自己，所以移动过去就行了，并不需要生成一个新的commit。

```
$ git merge dev

Updating 9242078..631ef3a
Fast-forward
 a.md | 2 ++
 1 file changed, 2 insertions(+)
```

```
C0 -- C1 -- C2 -- C3(HEAD -> master, dev)
```

这种操作在git中有一个专有名词，叫`Fast forward`。

比如说`git pull`的时候经常发生这种情况。通常因为远端有更新的commit我们才需要执行`git pull`命令，这时远端就是合并客体，本地就是合并主体，远端的分支指针在下游，也会触发`Fast forward`。

## 合并主体在合并客体的下游

如果合并主体在合并客体的下游，那合并主体本身就包含合并客体，合并操作并不会产生任何效果。

```
C0 -- C1 -- C2(dev) -- C3(HEAD -> master)
```

```
$ git merge dev

Already up to date.
```

```
C0 -- C1 -- C2(dev) -- C3(HEAD -> master)
```

依然用三方合并的概念来理解，这时`合并客体commit`与`合并主客体的共同祖先commit`是同一个commit，`合并客体commit`相对于`合并主客体的共同祖先commit`的diff为空，`合并主体commit`相对于`合并主客体的共同祖先commit`的diff与空diff合并还是它自己。但是这回它都不用移动，因为合并后的diff就是它自己原有的diff。

注意，这时候dev分支指针会不会动呢？

当然不会，`git merge`操作对合并客体是没有任何影响的。

## 同时合并多个客体

如果你在`git merge`后面跟不止一个分支，这意味着你想同时将它们合并进当前分支。

```
$ git merge aaa bbb ccc

Fast-forwarding to: aaa
Trying simple merge with bbb
Trying simple merge with ccc
Merge made by the 'octopus' strategy.
 aaa.md | 0
 bbb.md | 0
 ccc.md | 0
 3 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 aaa.md
 create mode 100644 bbb.md
 create mode 100644 ccc.md
```

git合并有多种策略，上面使用的是`'octopus' strategy`章鱼策略，因为同时合并的多个分支最终都会指向新的commit，看起来像章鱼的触手。

## 合并有冲突

`git merge`操作并不总是如此顺利的。因为有时候要合并的两个分支不是同一个人的，就会有很大的概率遇到两人同时修改文件某一行的情况。git不知道该用谁的版本，它认为两个分支遇到了冲突。

这时就需要开发者手动的解决冲突，才能让git继续合并。

```
$ git merge dev

Auto-merging a.md
CONFLICT (content): Merge conflict in a.md
Automatic merge failed; fix conflicts and then commit the result.
```

我们来看一下有冲突的文件是什么样的。

```
<<<<<<< HEAD
apple
=======
banana
>>>>>>> dev
```

运行`git status`命令。

```
$ git status

On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)
Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   a.md
no changes added to commit (use "git add" and/or "git commit -a")
```

解决完冲突之后，你需要再提交，告诉git可以完成合并了。

```
$ git commit -m "fix merge conflict"

U	a.md
error: Committing is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.
```

诶，被拒绝了。是不是想起了自己的情场故事？

当我们解决冲突的时候，工作区已经有改动，所以需要先提交到暂存区。

```
$ git add a.md
```

```
$ git commit -m "fix merge conflict"

[master 9b32d4d] fix merge conflict
```

运行`git add `命令之后你也可以用`git merge --continue`来替代`git commit`命令。它会让后面的行为跟没有冲突时的行为表现的一样。

如果你遇到冲突以后不知道如何解决，因为你要去询问你的合作伙伴为什么这样改。这时你肯定想回到合并以前的状态。

这对git来说很容易。只需要运行`git merge --abort`命令即可。

```
$ git merge --abort
```

该命令无法保证恢复工作区的修改，所以最好是在合并之前先让工作区保持干净。

Git 专题 05 —— merge


在git中，暂存区里有若干备份，版本库里有若干版本。留着这些东西肯定是拿来用的对吧，怎么用呢？当我需要哪一份的时候我就切换到哪一份。

`git checkout`命令就是用来干这个的，官方术语叫做`签出`。

怎么理解`checkout`这个词呢？`checkout`原本指的是消费结束服务员要与你核对一下账单，结完账之后你就可以走了。在git中核对指的是diff，比较两份版本的差异，如果发现没有冲突那就可以切换过来了。

## 底层

我们知道HEAD指针指向当前版本，而`git checkout`命令的作用是切换版本，它们肯定有所关联。

目前HEAD指针指向master分支。

```
$ cat .git/HEAD

ref: refs/heads/master
```

如果我切换到另一个分支，会发生什么？

```
$ git checkout dev

Switched to branch 'dev'
```

```
$ cat .git/HEAD

ref: refs/heads/dev
```

果然，`git checkout`命令的原理就是改变了HEAD指针。而一旦HEAD指针改变，git就会取出HEAD指针指向的版本作为当前工作目录的版本。签出到一个没有分支引用的commit也是一样的。

## 符号

在进入正题之前，我们要先聊聊git中的两个符号`~`和`^`。

如果我们要从一个分支切换到另一个分支，那还好说，足够语义化。但是如果我们要切换到某个commit，除了兢兢业业的找到它的SHA-1值，还有什么办法快速的引用到它呢？

比如说我们可以根据commit之间的谱系关系快速定位。

```
$ git log --graph --oneline

* 4e76510 (HEAD -> master) c4
*   2ec8374 c3
|\  
| * 7c0a8e3 c2
* | fb60f51 c1
|/  
* dc96a29 c0
```

>`~`的作用是在纵向上定位。它可以一直追溯到最早的祖先commit。如果commit历史有分叉，那它就选第一个，也就是主干上的那个。
>
>`^`的作用是在横向上定位。它无法向上追溯，但是如果commit历史有分叉，它能定位所有分叉中的任意一支。

#### HEAD不加任何符号、加`~0` 符号或者加`^0`符号时，定位的都是当前版本

这个不用说，定位当前commit。

```
$ git rev-parse HEAD

4e76510fe8bb3c69de12068ab354ef37bba6da9d
```

它表示定位第零代父commit，也就是当前commit。

```
$ git rev-parse HEAD~0

4e76510fe8bb3c69de12068ab354ef37bba6da9d
```

它表示定位当前commit的第零个父commit，也就是当前commit。

```
$ git rev-parse HEAD^0

4e76510fe8bb3c69de12068ab354ef37bba6da9d
```

#### 用`~`符号数量的堆砌或者`~数量`的写法定位第几代父commit

```
$ git rev-parse HEAD~~

fb60f519a59e9ceeef039f7efd2a8439aa7efd4b
```

```
$ git rev-parse HEAD~2

fb60f519a59e9ceeef039f7efd2a8439aa7efd4b
```

#### 用`^数量`的写法定位第几个父commit

注意，`^`定位的是当前基础的父commit。

```
$ git rev-parse HEAD^

2ec837440051af433677f786e502d1f6cdeb0a4a
```

```
$ git rev-parse HEAD^1

2ec837440051af433677f786e502d1f6cdeb0a4a
```

因为当前commit只有一个父commit，所以定位第二个父commit会失败。

```
$ git rev-parse HEAD^2

HEAD^2
fatal: ambiguous argument 'HEAD^2': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
```

#### 用`~数量^数量`的写法或者`^数量^数量`的写法定位第几代父commit的第几个父commit

当前commit的第一代父commit的第零个父commit，意思就是第一代父commit咯。

```
$ git rev-parse HEAD~^0

2ec837440051af433677f786e502d1f6cdeb0a4a
```

比如这里定位的是当前commit的第一代父commit的第一个父commit。再次注意，`^`定位的是当前基础的父commit。

```
$ git rev-parse HEAD~^1

fb60f519a59e9ceeef039f7efd2a8439aa7efd4b
```

这里定位的是当前commit的第一代父commit的第二个父commit。

```
$ git rev-parse HEAD~^2

7c0a8e3a325ce1b5a1cdeb8c89bef1ecf17c10c9
```

同样，定位到一个不存在的commit会失败。

```
$ git rev-parse HEAD~^3

HEAD~^3
fatal: ambiguous argument 'HEAD~^3': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
```

和`~`不同，`^2`和`^^`的效果是不一样的。`^2`指的是第二个父commit，`^^`指的是第一个父commit的第一个父commit。

## 切换到HEAD

`git checkout`命令如果不带任何参数，默认会加上HEAD参数。而HEAD指针指向的就是当前commit。所以它并不会有任何签出动作。

前面没有提到的是，`git checkout`命令会有一个顺带效果：比较签出后的版本和暂存区之间的差异。

所以`git checkout`命令不带任何参数，意思就是比较当前commit和暂存区之间的差异。

```
$ git checkout

A	b.md
```

```
$ git checkout HEAD

A	b.md
```

## 切换到commit

开发者用的最多的当然是切换分支。其实`checkout`后面不仅可以跟分支名，也可以跟commit的校验和，还可以用符号定位commit。

```
$ git checkout dev

Switched to branch 'dev'
```

```
$ git checkout acb71fe

Note: checking out 'acb71fe11f78d230b860692ea6648906153f3d27'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
  git checkout -b <new-branch-name>
HEAD is now at acb71fe... null
```

```
$ git checkout HEAD~2

Note: checking out 'acb71fe11f78d230b860692ea6648906153f3d27'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
  git checkout -b <new-branch-name>
HEAD is now at acb71fe... null
```

## 创建分支并切换

有时候我们在创建分支时希望同时切换到创建后的分支，仅仅`git branch <branch>`是做不到的。这时`git checkout`命令可以提供一个快捷操作，创建分支和切换分支一步到位。

```
$ git checkout -b dev

Switched to a new branch 'dev'
```

## 暂存区文件覆盖工作区文件

`git checkout`不仅可以执行切换commit这种全量切换，它还能以文件为单位执行微观切换。

```
$ git status

On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   a.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   a.md
```

```
$ git checkout -- a.md
```

```
$ git status

On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   a.md
```

因为暂存区覆盖了工作区，所以工作区的改动就被撤销了，现在只剩下暂存区的改动等待提交。其实相当于撤销文件在工作区的改动，只不过它的语义是覆盖。这个命令没有任何提示，直接撤销工作区改动，要谨慎使用。

我们看到git提示语中有一个`git checkout -- <file>`命令，这又是干嘛用的呢？

提醒一下，这个参数的写法不是`git checkout --<file>`，而是`git checkout -- <file>`。

其实它和`git checkout <file>`的效果是一样的。但是别急，我是说这两个命令**想要**达到的效果是一样的，但**实际**效果却有略微的差别。

独立的`--`参数在Linux命令行中指的是：视后面的参数为文件名。当后面跟的是文件名的时候，最好加上独立的`--`参数，以免有歧义。

也就是说，如果该项目正好有一个分支名为`a.md`(皮一下也不是不行对吧)，那加独立的`--`参数就不会操作分支，而是操作文件。

如果你觉得仅仅撤销一个文件在工作区的改动不过瘾，你不是针对谁，你是觉得工作区的改动都是垃圾。那么还有一个更危险的命令。

```
$ git checkout -- .
```

`.`代表当前目录下的所有文件和子目录。这条命令会撤销所有工作区的改动。

## 当前commit文件覆盖暂存区文件和工作区文件

如果执行`git checkout -- <file>`的时候加上一个分支名或者commit的校验和，效果就是该文件的当前版本会同时覆盖暂存区和工作区。相当于同时撤销文件在暂存区和工作区的改动。

```
$ git status

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   a.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   a.md
```

```
$ git checkout HEAD -- a.md
```

```
$ git status

On branch master
nothing to commit, working tree clean
```

最后再提醒一下，运行`git checkout`命令作用于文件时，即便覆盖内容与被覆盖内容有冲突，也会直接覆盖，所以这真的是闷声打雷式的git命令，一定要抽自己几个耳刮子方可放心食用。

Git 专题 04 —— checkout


分支是使得git如此灵活的强大武器，正是因为有巧妙的分支设计，众多的git工作流才成为可能。

现在我们已经知道commit对象其实就是git中的版本。那我们要在版本之间切换难道只能通过指定commit对象毫无意义的SHA-1值吗？

当然不是。

在git中，我们可以通过将一些指针指向commit对象来方便操作，这些指针便是分支。

> 分支在git中是一个模棱两可的概念。
>
> 你可以认为它仅仅是一个指针，指向一个commit对象节点。
>
> 你也可以认为它是指针指向的commit对象节点追溯到某个交叉节点之间的commit历史。

严格的来说，一种叫分支指针，一种叫分支历史。不过实际使用中，它们在名字上常常不作区分。

所以我们需要意会文字背后的意思，它究竟说的是分支指针还是分支历史。

大多数时候，它指的都是分支指针。

## master分支

刚刚初始化的git仓库，会发现`.git/refs/heads`目录下面是空的。这是因为目前版本库里还没有任何commit对象，而分支一定是指向commit对象的。

一旦版本库里有了第一个commit对象，git都会在`.git/refs/heads`目录下面自动生成一个`master`文件，它就是git的默认分支。不过它并不特殊，只是它充当的是一个默认角色而已。

刚刚初始化的git仓库会显示目前在master分支上，其实这个master分支是假的，`.git/refs/heads`目录下根本没有这个文件。只有等提交历史不为空时才有会真正的默认分支。

我们看一下`master`文件到底有什么。

```
$ cat .git/refs/heads/master

6b5a94158cc141286ac98f30bb189b8a83d61347
```

40个字符，明显是某个git对象的引用。再识别一下它的类型，发现是一个commit对象。

```
$ git cat-file -t 6b5a941

commit
```

就这么简单，所谓的分支(分支指针)就是一个指向某个commit对象的指针。

## HEAD指针

形象的讲，HEAD就是景区地图上标注你当前在哪里的一个图标。

你当前在哪里，HEAD就在哪里。它一般指向某个分支，因为一般我们都会在某个分支之上。

因为HEAD是用来标注当前位置的，所以一旦HEAD的位置被改变，工作目录就会切换到HEAD指向的分支。

```
$ git log --oneline

f53aaa7 (HEAD -> master) commit for nothing
```

但是也有例外，比如我直接签出到某个没有分支引用的commit。

```
$ git log --oneline

cb64064 (HEAD -> master) commit for nothing again
324a3c0 commit for nothing
```

```
$ git checkout 324a3c0

Note: checking out '324a3c0'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
  git checkout -b <new-branch-name>
HEAD is now at 324a3c0... commit for nothing
```

```
$ git log --oneline

324a3c0 commit for nothing
```

这个时候的HEAD就叫做`detached HEAD`。

要知道，只有在初始提交和某个分支之间的commit才是有效的。当你的HEAD处于`detached HEAD`状态时，在它之上新建的commit没有被任何分支包裹。一旦你切换到别的分支，这个commit(可能)再也不会被引用到，最终会被垃圾回收机制删除。因此这是很危险的操作。

```
324a3c0 -- cb64064(master)
   \
 3899a24(HEAD)
```

如果不小心这么做了，要么在原地新建一个分支，要么将已有的分支强行移动过来。确保它不会被遗忘。

> 死亡不是终结，遗忘才是。——寻梦环游记

## 创建

除了默认的`master`分支，我们可以随意创建新的分支。

```
$ git branch dev
```

一个dev分支就创建好了。

## 查看

或许有时我们也想要查看本地仓库有多少个分支，因为在git中新建分支实在是太容易了。

```
$ git branch

  dev
* master
```

当前分支的前面会有一个`*`号标注。

同时查看本地分支和远端分支引用，添加`-a`参数。

```
$ git branch -a

* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
```

## 删除

一般分支合并完之后就不再需要了，这时就要将它删除。

```
$ git branch -d dev

Deleted branch dev (was 657142d).
```

有时候我们会得到不一样的提示。

```
$ git branch -d dev

error: The branch 'dev' is not fully merged.
If you are sure you want to delete it, run 'git branch -D dev'.
```

这是git的一种保护措施。`is not fully merged`是针对当前分支来说的，意思是你要删除的分支还有内容没有合并进**当前分支**，你确定要删除它吗？

大多数时候，当然是要的。

```
$ git branch -D dev

Deleted branch dev (was 657142d).
```

`-D`是`--delete --force`的缩写，你也可以写成`-df`。

需要注意的是，删除分支仅仅是删除一个指针而已，并不会删除对应的commit对象。不过有可能删除分支以后，这一串commit对象就无法再被引用了，从而被垃圾回收机制删除。

Git 专题 03 —— branch


git是一个版本管理系统。它的终极目的就是将项目特定时间的信息保留成一个版本，以便将来的回退和查阅。

我们已经介绍了暂存区，暂存区的下一步就是版本库，而促成这一步操作的是`git commit`命令。

## 提交

暂存区有待提交内容的情况下，如果直接运行`git commit`命令，git会跳往默认编辑器要求你输入提交说明，你也可以自定义要跳往的编辑器。

```

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Initial commit
# Changes to be committed:
#	new file:   a.md
```

提交之后我们就看到这样的信息。

```
[master (root-commit) 99558b4] commit for nothing
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 a.md
```

如果我就是不写提交说明呢？

```
Aborting commit due to empty commit message.
```

看到没有，提交信息在git中时必填的。

如果提交说明不多，可以加参数`-m`直接在命令后面填写提交说明。

```
$ git commit -m "commit for nothing"
```

你甚至可以将加入暂存区和提交一并做了。

```
$ git commit -am "commit for nothing"
```

但是要注意，和`git add -u`命令一样，未跟踪的文件是无法提交上去的。

## 重写提交

`amend`翻译成中文是`修改`的意思。`git commit --amend`命令允许你修改最近的一次commit。

```
$ git log --oneline

8274473 (HEAD -> master) commit for nothing
```

目前项目提交历史中只有一个commit。我突然想起来这次提交中有一个笔误，我把`高圆圆`写成了`高晓松`(真的是笔误)。但是呢，我又不想为了这个笔误增加一个commit，毕竟它仅仅是一个小小的笔误而已。最重要的是我想悄无声息的改正它，以免被别人笑话。

这时我就可以使用`git commit --amend`命令。

首先修改`高晓松`成`高圆圆`。

然后执行`git add a.md`命令。

最后重写提交。git会跳往默认或者自定义编辑器提示你修改commit说明。当然你也可以不改。

```
$ git commit --amend

commit for nothing
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# Date:      Thu Jan 3 09:33:56 2019 +0800
# On branch master
# Initial commit
# Changes to be committed:
#	new file:   a.md
```

我们再来看提交历史。

```
$ git log --oneline

8a71ae1 (HEAD -> master) commit for nothing
```

提交历史中同样只有一个commit。但是注意哟，commit已经不是之前的那个commit了，它们的校验和是不一样的。这就是所谓的重写。

## tree对象和commit对象

commit操作涉及到两个git对象。

第一是tree对象。

它存储子目录和子文件的引用。如果只有blob对象，那版本库将是一团散沙。正因为有tree对象将它们的关系登记在册，才能构成一个有结构的版本库。

添加到暂存区操作并不会生成tree对象，这时项目的结构信息存储在`index`文件中，直到提交版本库操作，才会为每一个目录分别生成tree对象。

第二是commit对象。

它存储每个提交的信息，包括当前提交的根tree对象的引用，父commit对象的引用，作者和提交者，还有提交信息。所谓的版本，其实指的就是这个commit对象。

作者和提交者通常是一个人，但也存在不同人的情况。

## objects

初始化一个git项目，新建一些文件和目录。

```
src/
src/a.md
lib/
lib/b.md
```

首先运行`git add`命令。我们清楚，这会在`.git/objects`目录下生成一个blob对象，因为目前两个文件都是空文件，共享一个blob对象。

```
.git/objects/info/
.git/objects/pack/
.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
```

现在我们运行`git commit`命令，看看有什么变化。

```
.git/objects/info/
.git/objects/pack/
.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
.git/objects/93/810bbde0f994d41ef550324a2c1ad5f9278e19
.git/objects/52/0c9f9f61657ca1e65a288ea77d229a27a8171b
.git/objects/0b/785fa11cd93f95b1cab8b9cbab188edc7e04df
.git/objects/49/11ff67189d8d5cc2f94904fdd398fc16410d56
```

有意思。刚刚只有一个blob对象，怎么突然蹦出来这么多git对象呢？想一想之前说的`commit操作涉及到两个git对象`这句话，有没有可能多出来的几个，分别是tree对象和commit对象？

我们使用git底层命令`git cat-file -t <commit>`查看这些对象的类型发现，其中有一个blob对象，三个tree对象，一个commit对象。

这是第一个tree对象。

```
$ git cat-file -t 93810bb

tree
```

```
$ git cat-file -p 93810bb

100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	b.md
```

这是第二个tree对象。

```
$ git cat-file -t 520c9f9

tree
```

```
$ git cat-file -p 520c9f9

100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	a.md
```

这是第三个tree对象。

```
$ git cat-file -t 0b785fa

tree
```

```
$ git cat-file -p 0b785fa

040000 tree 93810bbde0f994d41ef550324a2c1ad5f9278e19	lib
040000 tree 520c9f9f61657ca1e65a288ea77d229a27a8171b	src
```

可以看到，提交时每个目录都会生成对应的tree对象。

然后我们再来看commit对象。

```
$ git cat-file -t 4911ff6

commit
```

```
$ git cat-file -p 4911ff6

tree 0b785fa11cd93f95b1cab8b9cbab188edc7e04df
parent c4731cfab38f036c04de93facf07cae496a124a2
author veedrin <veedrin@qq.com> 1546395770 +0800
committer veedrin <veedrin@qq.com> 1546395770 +0800
commit for nothing
```

可以看到，commit会关联根目录的tree对象，因为关联它就可以关联到所有的项目结构信息，所谓擒贼先擒王嘛。它也要关联父commit，也就是它的上一个commit，这样才能组成版本历史。当然，如果是第一个commit那就没有父commit了。然后就是commit说明和一些参与者信息。

我们总结一下，`git add`命令会为加入暂存区的内容或文件生成blob对象，`git commit`命令会为加入版本库的内容或文件生成tree对象和commit对象。至此，四种git对象我们见识了三种。

为啥不在`git add`的时候就生成tree对象呢？

所谓暂存区，就是不一定会保存为版本的信息，只是一个准备的临时场所。git认为在`git add`的时候生成tree对象是不够高效的，完全可以等版本定型时再生成。而版本定型之前的结构信息存在`index`文件中就好了。

Git 专题 02 —— commit


git是一个数据库系统，git是一个内容寻址文件系统，git是一个版本管理系统。

没错，它都是。

不过我们不纠结于git是什么，我们单刀直入，介绍git命令。

要将未跟踪的文件和已跟踪文件的改动加入暂存区，我们可以使用`git add`命令。

不过很多人嫌`git add`命令不够语义化，毕竟这一步操作是加入暂存区呀。所以git又增加了另外一个命令`git stage`，它们的效果是一模一样的。

## git仓库、工作区和暂存区

进入主题之前，我们先要介绍一下git仓库、工作区和暂存区的概念。

#### git仓库

所谓的git仓库就是一个有`.git`目录的文件夹。它是和git有关的一切故事开始的地方。

可以使用`git init`命令初始化一个git仓库。

```
$ git init
```

也可以使用`git clone`命令从服务器上克隆仓库到本地。

```
$ git clone git@github.com:veedrin/horseshoe.git
```

然后你的本地就有了一个和服务器上一模一样的git仓库。

这里要说明的是，`clone`操作并不是将整个仓库下载下来，而是只下载`.git`目录。因为关于git的一切秘密都在这个目录里面，只要有了它，git就能复原到仓库的任意版本。

#### 工作区(working directory)

工作区，又叫工作目录，就是不包括`.git`目录的项目根目录。我们要在这个目录下进行手头的工作，它就是版本管理的素材库。你甚至可以称任何与工作有关的目录为工作区，只不过没有`.git`目录git是不认的。

#### 暂存区(stage或者index)

`stage`在英文中除了有`舞台、阶段`之意外，还有作为动词的`准备、筹划`之意，所谓的暂存区就是一个为提交到版本库做准备的地方。

那它为什么又被称作`index`呢？因为暂存区在物理上仅仅是`.git`目录下的`index`二进制文件。它就是一个索引文件，将工作区中的文件和暂存区中的备份一一对应起来。

`stage`是表意的，`index`是表形的。

你可以把暂存区理解为一个猪猪储钱罐。我们还是孩子的时候，手里有一毛钱就会丢进储钱罐里。等到储钱罐摇晃的声音变的浑厚时，或者我们有一个心愿急需用钱时，我们就砸开储钱罐，一次性花完。

类比到软件开发，每当我们写完一个小模块，就可以将它放入暂存区。等到一个完整的功能开发完，我们就可以从暂存区一次性提交到版本库里。

这样做的好处是明显的：

- 它可以实现更小颗粒度的撤销。
- 它可以实现批量提交到版本库。

另外，添加到暂存区其实包含两种操作。一种是将还未被git跟踪过的文件放入暂存区；一种是已经被git跟踪的文件，将有改动的内容放入暂存区。

## 放入暂存区

git默认是不会把工作区的文件放入暂存区的。

```
$ git status

On branch master
No commits yet
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	a.md
nothing added to commit but untracked files present (use "git add" to track)
```

我们看到文件现在被标注为`Untracked files`。表示git目前还无法追踪它们的变化，也就是说它们还不在暂存区里。

那么我们如何手动将文件或文件夹放入暂存区呢？

```
$ git add .
```

上面的命令表示将工作目录所有未放入暂存区的文件都放入暂存区。这时文件的状态已经变成了`Changes to be committed`，表示文件已经放入暂存区，等待下一步提交。每一次add操作其实就是为加入的文件或内容生成一份备份。

下面的命令也能达到相同的效果。

```
$ git add -A
```

假如我只想暂存单个文件呢？后跟相对于当前目录的文件名即可。

```
$ git add README.md
```

暂存整个文件夹也是一样的道理。因为git会递归暂存文件夹下的所有文件。

```
$ git add src
```

把从来没有被标记过的文件放入暂存区的命令是`git add`，暂存区中的文件有改动也需要使用`git add`命令将改动放入暂存区。

这时状态变成了`Changes not staged for commit`。

```
$ git status

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   a.md
no changes added to commit (use "git add" and/or "git commit -a")
```

针对已经加入暂存区的文件，要将文件改动加入暂存区，还有一个命令。

```
$ git add -u
```

它和`git add -A`命令的区别在于，它只能将已加入暂存区文件的改动放入暂存区，而`git add -A`通吃两种情况。

## 跟踪内容

假设我们已经将文件加入暂存区，现在我们往文件中添加内容，再次放入暂存区，然后查看状态。

```
$ git status

On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   a.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   a.md
```

哎，突然变的有意思了。为什么一个文件会同时存在两种状态，它是薛定谔的猫么？

想象一下，我想在一个文件中先修复一个bug然后增加一个feather，我肯定希望分两次放入暂存区，这样可以实现颗粒度更细的撤销和提交。但是如果git是基于文件做版本管理的，它就无法做到。

所以git只能是基于内容做版本管理，而不是基于文件。版本管理的最小单位叫做hunk，所谓的hunk就是一段连续的改动。一个文件同时有两种状态也就不稀奇了。

## objects

git项目的`.git`目录下面有一个目录`objects`，一开始这个目录下面只有两个空目录：`info`和`pack`。

一旦我们执行了`git add`命令，`objects`目录下面就会多出一些东西。

```
.git/
.git/objects/
.git/objects/e6/
.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
```

它多出了一个2个字符命名的目录和一个38个字符命名的文件。加起来正好是40个字符。增加一个2个字符的目录是为了提高检索效率。

SHA-1是一种哈希加密算法，它的特点是只要加密的内容相同，得到的校验和也相同。当然这种说法是不准确的，但是碰撞的概率极低。

git除了用内容来计算校验和之外，还加入了一些其他信息，目的也是为了进一步降低碰撞的概率。

重点是，SHA-1算法是根据内容来计算校验和的，跟前面讲的git跟踪内容相呼应。git被称为一个内容寻址文件系统不是没有道理的。

我们可以做个实验。初始化本地仓库两次，每次都新建一个markdown文件，里面写`## git is awesome`，记下完整的40个字符的校验和，看看它们是否一样。

```
.git/objects/56/46a656f6331e1b30988472fefd48686a99e10f
```

如果你真的做了实验，你会发现即便两个文件的文件名和文件格式都不一样，只要内容一样，它们的校验和就是一样的，并且就是上面列出的校验和。

现在大家应该对`git跟踪内容`这句话有更深的理解了。

#### 相同内容引用一个对象

虽然开发者要极力避免这种情况，但是如果一个仓库有多个内容相同的文件，git会如何处理呢？

我们初始化一个本地仓库，新建两个不同名的文件，但文件内容都是`## git is awesome`。运行`git add .`命令之后看看神秘的`objects`目录下会发生什么？

```
.git/objects/56/46a656f6331e1b30988472fefd48686a99e10f
```

只有一个目录，而且校验和跟之前一模一样。

其实大家肯定早就想到了，git这么优秀的工具，怎么可能会让浪费磁盘空间的事情发生呢？既然多个文件的内容相同，肯定只保存一个对象，让它们引用到这里来就好了。

#### 文件改动对应新对象

现在我们猜测工作区的文件和`objects`目录中的对象是一一对应起来的。但事实真的是这样吗？

我们初始化一个本地仓库，新建一个markdown文件，运行`git add .`命令。现在`objects`目录中已经有了一个对象。然后往文件中添加内容`## git is awesome`。再次运行`git add .`命令。

```
.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
.git/objects/56/46a656f6331e1b30988472fefd48686a99e10f
```

哎，`objects`目录中出现了两个对象。第一个对象肯定对应空文件。第二个对象我们太熟悉了，对应的是添加内容后的文件。

再次强调，git是一个版本管理系统，文件在它这里不是主角，版本才是。刚才我们暂存了两次，可以认为暂存区现在已经有了两个版本(暂存区的版本实际上是内容备份，并不是真正的版本)。当然就需要两个对象来保存。

#### 文件改动全量保存

初始化一个本地仓库，往工作区添加`lodash.js`未压缩版本，版本号是`4.17.11`，体积大约是`540KB`。运行`git add .`命令后`objects`目录下面出现一个对象，体积大约是`96KB`。

```
.git/objects/cb/139dd81ebee6f6ed5f5a9198471f5cdc876d70
```

我们对`lodash.js`文件内容作一个小小的改动，将版本号从`4.17.11`改为`4.17.10`，再次运行`git add .`命令。然后大家会惊奇的发现`objects`目录下有两个对象了。惊奇的不是这个，而是第二个对象的体积也是大约`96KB`。

```
.git/objects/cb/139dd81ebee6f6ed5f5a9198471f5cdc876d70
.git/objects/bf/c087eec7e61f106df8f5149091b8790e6f3636
```

明明只改了一个数字而已，第二个对象却还是这么大。

前面刚夸git会精打细算，怎么到这里就不知深浅了？这是因为多个文件内容相同的情况，引用到同一个对象并不会造成查询效率的降低，而暂存区的多个对象之间如果只保存增量的话，版本之间的查询和切换需要花费额外的时间，这样做是不划算的。

但是全量保存也不是个办法吧。然而git鱼和熊掌想兼得，它也做到了。后面会讲到。

#### 重命名会拆分成删除和新建两个动作

初始化一个本地仓库，新建一个文件，运行`git add .`命令。然后重命名该文件，查看状态信息。

```
$ git status

On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   a.md
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	deleted:    a.md
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	b.md
```

这是由于git的内部机制导致的。生成对象的时候，它发现仓库中叫这个名字的文件不见了，于是标记为已删除，又发现有一个新的文件名是之前没有标记过的，于是标记为未跟踪。因为它只是重命名而已，文件内容并没有改变，所以可以共享对象，并不会影响效率。

## blob对象

git的一切秘密都在`.git`目录里。因为它拥有项目的完整信息，所以git一定是把备份存在了某个地方。git把它们存在了哪里，又是如何存储它们的呢？

这些备份信息，git统一称它们为对象。git总共有四种对象类型，都存在`.git/objects`目录下。

这一次我们只介绍blob对象。

它存储文件的内容和大小。当开发者把未跟踪的文件或跟踪文件的改动加入暂存区，就会生成若干blob对象。git会对blob对象进行`zlib`压缩，以减少空间占用。

因为它只存储内容和大小，所以两个文件即便文件名和格式完全不一样，只要内容相同，就可以共享一个blob对象。

注意blob对象和工作目录的文件并不是一一对应的，因为工作目录的文件几乎会被多次添加到暂存区，这时一个文件会对应多个blob对象。

## index

仓库的`.git`目录下面有一个文件，它就是大名鼎鼎的暂存区。

是的，暂存区并不是一块区域，只是一个文件，确切的说，是一个索引文件。

它保存了项目结构、文件名、时间戳以及blob对象的引用。

工作区的文件和blob对象之间就是通过这个索引文件关联起来的。

## 打包

还记得我们在`文件改动全量保存`小节里讲到，git鱼和熊掌想兼得么？

又想全量保存，不降低检索和切换速度，又想尽可能压榨体积。git是怎么做到的呢？

git会定期或者在推送到远端之前对git对象进行打包处理。

打包的时候保存文件最新的全量版本，基于该文件的历史版本的改动则只保存diff信息。因为开发者很少会切换到较早的版本中，所以这时候效率就可以部分牺牲。

需要注意的是，所有的git对象都会被打包，而不仅仅是blob对象。

git也有一个`git gc`命令可以手动执行打包。

```
$ git gc

Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (11/11), done.
Total 11 (delta 3), reused 0 (delta 0)
```

之前的git对象文件都不见了，`pack`文件夹多了两个文件。其中 `.pack` 后缀文件存储的就是打包前git对象文件的实际内容。

```
.git/objects/
.git/objects/info/
.git/objects/info/packs
.git/objects/pack/
.git/objects/pack/pack-99b4704a207ea3cc4924c9f0febb6ea45d4cdfd2.idx
.git/objects/pack/pack-99b4704a207ea3cc4924c9f0febb6ea45d4cdfd2.pack
```

只能说，`git gc`的语义化不够好。它的功能不仅仅是垃圾回收，还有打包。

Git 专题 01 —— add

我们说正则表达式是语言无关的，是因为驱动正则表达式的引擎是相似的。鉴于正则表达式是一种古老的语法，它的引擎也在历史长河中衍生出了几个大的分支。

我会关注到正则表达式引擎这样比较底层的实现，缘起于在一次业务实践中，追踪到一个由正则引起的BUG。业务中使用的一个markdown解析库`Remarkable`在解析一段不规则文本时引起浏览器崩溃，调试之后发现是某一个正则在匹配时陷入了死循环，严格的说(后来才知道)是匹配花费了过多时间导致浏览器卡死。

我当时很震惊，正则匹配的性能不是很高的么？匹配到就是匹配到，没匹配到就是没匹配到，怎么会在里面走不出来了呢？

## 有限自动机

什么叫有限自动机(Finite Automate)呢？

我们把有限自动机理解为一个机器人，在这个机器人眼里，所有的事物都是由有限节点组成的。机器人按照顺序读取有限节点，并表达成有限状态，最终机器人输出`接受`或者`拒绝`作为结束。

关注它的两个特点：

- 有限状态集。
- 只根据当前状态和当前输入来决定下一个状态。它有点一板一眼。

怎么理解第二个特点？我们看一个例子：

```javascript
'aab'.match(/a*?b/);
// ["aab", index: 0, input: "aab", groups: undefined]
```

我们知道`*?`是非贪婪匹配，按照我们人类灵活的尿性，直接把匹配结果`ab`甩他脸上。

但有限自动机不会。第一步它用`a`匹配`a`非常完美，然后发现对于`a`是非贪婪模式，于是试着用`b`匹配下一个`a`，结果非常沮丧。于是它只能继续用`a`匹配，匹配成功后依然没忘非贪婪特性，继续试着用`b`匹配下一个字符`b`，成功，收官。

其实写出这段代码的开发者想要的结果应该是`ab`，但有限自动机从来不仰望星空，只低头做事，一板一眼的根据当前状态和当前输入来决定下一个状态。

## DFA与NFA

有限自动机大体上又可以分为两类：DFA是`确定性有限自动机`的缩写，NFA是`非确定性有限自动机`的缩写。

我没办法告诉你DFA与NFA在原理上的差别，但咱们可以探讨一下它们在处理正则上的表现差异。

总的来说，DFA可以称为文本主导的正则引擎，NFA可以称为表达式主导的正则引擎。

怎么讲？

我们常常说用正则去匹配文本，这是NFA的思路，DFA本质上其实是用文本去匹配正则。哪个是攻，哪个是受，大家心里应该有个B数了吧。

我们来看一个例子：

```javascript
'tonight'.match(/to(nite|knite|night)/);
```

如果是NFA引擎，表达式占主导地位。表达式中的`t`和`o`不在话下。然后就面临三种选择，它也不嫌累，每一种都去尝试一下，第一个分支在`t`这里停止了，接着第二个分支在`k`这里也停止了。终于在第三个分支柳暗花明，找到了自己的归宿。

换作是DFA引擎呢，文本占主导地位。同样文本中的`t`和`o`不在话下。文本走到`n`时，它发现正则只有两个分支符合要求，经过`i`走到`g`的时候，只剩一个分支符合要求了。当然，还要继续匹配。果然没有令它失望，第三个分支完美符合要求，下班。

大家发现什么问题了吗？

只有正则表达式才有分支和范围，文本仅仅是一个字符流。这带来什么样的后果？就是NFA引擎在匹配失败的时候，如果有其他的分支或者范围，它会返回，记住，返回，去尝试其他的分支。而DFA引擎一旦匹配失败，就结束了，它没有退路。

这就是它们之间的本质区别。其他的不同都是这个特性衍生出来的。

首先，正则表达式在计算机看来只是一串符号，正则引擎首先肯定要解析它。NFA引擎只需要编译就好了；而DFA引擎则比较繁琐，编译完还不算，还要遍历出表达式中所有的可能。因为对DFA引擎来说机会只有一次，它必须得提前知道所有的可能，才能匹配出最优的结果。

所以，在编译阶段，NFA引擎比DFA引擎快。

其次，DFA引擎在匹配途中一遍过，溜得飞起。相反NFA引擎就比较苦逼了，它得不厌其烦的去尝试每一种可能性，可能一段文本它得不停返回又匹配，重复好多次。当然运气好的话也是可以一遍过的。

所以，在运行阶段，NFA引擎比DFA引擎慢。

最后，因为NFA引擎是表达式占主导地位，所以它的表达能力更强，开发者的控制度更高，也就是说开发者更容易写出性能好又强大的正则来，当然也更容易造成性能的浪费甚至撑爆CPU。DFA引擎下的表达式，只要可能性是一样的，任何一种写法都是没有差别(可能对编译有细微的差别)的，因为对DFA引擎来说，表达式其实是死的。而NFA引擎下的表达式，高手写的正则和新手写的正则，性能可能相差10倍甚至更多。

也正是因为主导权的不同，正则中的很多概念，比如非贪婪模式、反向引用、零宽断言等只有NFA引擎才有。

所以，在表达能力上，NFA引擎秒杀DFA引擎。

当今市面上大多数正则引擎都是NFA引擎，应该就是胜在表达能力上。

## 测试引擎类型

现在我们知道正则表达式的驱动引擎分为两大类：DFA引擎与NFA引擎。

但是因为NFA引擎比较灵活，很多语言在实现上有细微的差别。所以后来大家弄了一个标准，符合这个标准的正则引擎就叫做POSIX NFA引擎，其余的就只能叫做传统型NFA引擎咯。

我们来看看JavaScript到底是哪种引擎类型吧。

```javascript
'123456'.match(/\d{3,6}/);
// ["123456", index: 0, input: "123456", groups: undefined]
'123456'.match(/\d{3,6}?/);
// ["123", index: 0, input: "123456", groups: undefined]
```

《精通正则表达式》书中说POSIX NFA引擎不支持非贪婪模式，很明显JavaScript不是POSIX NFA引擎。

> TODO: 为什么POSIX NFA引擎不支持也没有必要支持非贪婪模式？

区分DFA引擎与传统型NFA引擎就简单咯，捕获组你有么？花式零宽断言你有么？

结论就是：JavaScript的正则引擎是传统型NFA引擎。

## 回溯

现在我们知道，NFA引擎是用表达式去匹配文本，而表达式又有若干分支和范围，一个分支或者范围匹配失败并不意味着最终匹配失败，正则引擎会去尝试下一个分支或者范围。

正是因为这样的机制，引申出了NFA引擎的核心特点——回溯。

首先我们要区分备选状态和回溯。

什么是备选状态？就是说这一个分支不行，那我就换一个分支，这个范围不行，那我就换一个范围。正则表达式中可以商榷的部分就叫做备选状态。

备选状态是个好东西，它可以实现模糊匹配，是正则表达能力的一方面。

回溯可不是个好东西。想象一下，面前有两条路，你选择了一条，走到尽头发现是条死路，你只好原路返回尝试另一条路。这个原路返回的过程就叫回溯，它在正则中的含义是吐出已经匹配过的文本。

我们来看两个例子：

```javascript
'abbbc'.match(/ab{1,3}c/);
// ["abbbc", index: 0, input: "abbbc", groups: undefined]
'abc'.match(/ab{1,3}c/);
// ["abc", index: 0, input: "abc", groups: undefined]
```

第一个例子，第一次`a`匹配`a`成功，接着碰到贪婪匹配，不巧正好是三个`b`贪婪得逞，最后用`c`匹配`c`成功。

| 正则       | 文本  |
| ---------- | ----- |
| /a/        | a     |
| /ab{1,3}/  | ab    |
| /ab{1,3}/  | abb   |
| /ab{1,3}/  | abbb  |
| /ab{1,3}c/ | abbbc |

第二个例子的区别在于文本只有一个`b`。所以表达式在匹配第一个`b`成功后继续尝试匹配`b`，然而它见到的只有黄脸婆`c`。不得已将`c`吐出来，委屈一下，毕竟贪婪匹配也只是尽量匹配更多嘛，还是要臣服于匹配成功这个目标。最后不负众望用`c`匹配`c`成功。

| 正则       | 文本 |
| ---------- | ---- |
| /a/        | a    |
| /ab{1,3}/  | ab   |
| /ab{1,3}/  | abc  |
| /ab{1,3}/  | ab   |
| /ab{1,3}c/ | abc  |

请问，第二个例子发生回溯了吗？

**并没有。**

诶，你这样就不讲道理了。不是把`c`吐出来了嘛，怎么就不叫回溯了？

> 回溯是吐出已经匹配过的文本。匹配过程中造成的匹配失败不算回溯。

为了让大家更好的理解，我举一个例子：

> 你和一个女孩子(或者男孩子)谈恋爱，接触了半个月后发现实在不合适，于是提出分手。这不叫回溯，仅仅是不合适而已。
>
> 你和一个女孩子(或者男孩子)谈恋爱，这段关系维持了两年，并且已经同居。但由于某些不可描述的原因，疲惫挣扎之后，两人最终还是和平分手。这才叫回溯。
>
> 虽然都是分手，但你们应该能理解它们的区别吧。

网络上有很多文章都认为上面第二个例子发生了回溯。至少根据我查阅的资料，第二个例子发生的情况不能被称为回溯。当然也有可能我是错的，欢迎讨论。

我们再来看一个真正的回溯例子：

```javascript
'ababc'.match(/ab{1,3}c/);
// ["abc", index: 2, input: "ababc", groups: undefined]
```

匹配文本到`ab`为止，都没什么问题。然而苍天饶过谁，后面既匹配不到`b`，也匹配不到`c`。引擎只好将文本`ab`吐出来，从下一个位置开始匹配。因为上一次是从第一个字符`a`开始匹配，所以下一个位置当然就是从第二个字符`b`开始咯。

| 正则       | 文本    |
| ---------- | ------- |
| /a/        | a       |
| /ab{1,3}/  | ab      |
| /ab{1,3}/  | aba     |
| /ab{1,3}/  | ab      |
| /ab{1,3}c/ | aba     |
| /a/        | `a`b    |
| /a/        | `ab`a   |
| /ab{1,3}/  | `ab`ab  |
| /ab{1,3}/  | `ab`abc |
| /ab{1,3}/  | `ab`ab  |
| /ab{1,3}c/ | `ab`abc |

一开始引擎是以为会和最早的`ab`走完余生的，然而命运弄人，从此天涯。

这他妈才叫回溯！

还有一个细节。上面例子中的回溯并没有往回吐呀，吐出来之后不应该往回走嘛，怎么往后走了？

我们再来看一个例子：

```javascript
'"abc"def'.match(/".*"/);
// [""abc"", index: 0, input: ""abc"def", groups: undefined]
```

因为`.*`是贪婪匹配，所以它把后面的字符都吞进去了。直到发现目标完不成，不得已往回吐，吐到第二个`"`为止，终于匹配成功。这就好比结了婚还在外面养小三，几经折腾才发现家庭才是最重要的，自己的行为背离了初衷，于是幡然悔悟。

| 正则   | 文本     |
| ------ | -------- |
| /"/    | "        |
| /".*/  | "a       |
| /".*/  | "ab      |
| /".*/  | "abc     |
| /".*/  | "abc"    |
| /".*/  | "abc"d   |
| /".*/  | "abc"de  |
| /".*/  | "abc"def |
| /".*"/ | "abc"def |
| /".*"/ | "abc"de  |
| /".*"/ | "abc"d   |
| /".*"/ | "abc"    |

我想说的是，不要被`回溯`的`回`字迷惑了。它的本质是把已经吞进去的字符吐出来。至于吐出来之后是往回走还是往后走，是要根据情况而定的。

## 回溯引发的浏览器卡死惨案

现在我邀请读者回到文章开始提起的正则BUG。

```javascript
`
<img src=# onerror=’alert(document.cookie)/>/g);
```

这是测试妹子用于测试XSS攻击的一段代码，测试的脑洞你不要去猜。正则是`Remarkable`用于匹配注释的，虽然我没搞清楚到底为什么这样写。src我篡改了一下，不影响效果。

不怕事大的可以去Chrome开发者工具跑上一跑。

不卖关子。它会导致浏览器卡死，是因为分支和范围太多了。`[^-]+`是一个范围，`[-][^-]+`是一个范围，`[^-]+|[-][^-]+`是一个分支，`([^-]+|[-][^-]+)*`又是一个范围。另外注意，嵌套的分支和范围生成的备选状态是呈指数级增长的。

我们知道这段语句肯定会匹配失败，因为文本中压根就没有`-->`。那浏览器为什么会卡死呢？因为正则引擎的回溯实在过多，导致浏览器的CPU进程飙到`98%`以上。这和你在Chrome开发者工具跑一段巨大运算量的for循环是一个道理。

但是呢，正则永远不会走入死循环。正则引擎叫有限状态机，就是因为它的备选状态是有限的。既然是有限的，那就一定可以遍历完。10的2次方叫有限，10的200000000次方也叫有限。只不过计算机的硬件水平有限，容不得你进行这么大的运算量。我以前也以为是正则进入了死循环，其实这种说法是不对的，应该叫浏览器卡死或者撑爆CPU。

那么，怎么解决？

最粗暴也最贵的方式当然是换一台计算机咯。拉一台超级计算机过来肯定是可以打服它的吧。

第二就是减少分支和范围，尤其是嵌套的分支和范围。因为分支和范围越多，备选状态就越多，早早的就匹配成功还好，如果匹配能成功的备选状态在很后头或者压根就无法匹配成功，那你家的CPU就得嗷嗷叫咯。

我们来看一下：

```javascript
`
<img src=# onerror=’alert(document.cookie)/>
`.match(//g);
// [""]
```

你看，备选状态再多，我已经找到了我的白马王子，你们都歇着去吧。

这个正则我不知道它这样写的用意何在，所以也不知道怎么优化。明白备选状态是回溯的罪魁祸首就好了。

第三就是缩减文本。会发生回溯的情况，其实文本也是一个变量。你想想，总要往回跑，如果路途能短一点是不是也不那么累呢？

```javascript
'/g);
// null
```

试的时候悠着点，不同的浏览器可能承受能力不一样，你可以一个个字符往上加，看看极限在哪里。

当然，缩减文本是最不可行的。正则正则，就是不知道文本是什么才用正则呀。

## 优化正则表达式

现在我们知道了控制回溯是控制正则表达式性能的关键。

控制回溯又可以拆分成两部分：第一是控制备选状态的数量，第二是控制备选状态的顺序。

备选状态的数量当然是核心，然而如果备选状态虽然多，却早早的匹配成功了，早匹配早下班，也就没那么多糟心事了。

至于面对具体的正则表达式应该如何优化，那就是经验的问题了。思考和实践的越多，就越游刃有余。无他，唯手熟尔。

## 工具

[ [regex101](https://regex101.com/) ]是一个很多人推荐过的工具，可以拆分解释正则的含义，还可以查看匹配过程，帮助理解正则引擎。如果只能要一个正则工具，那就是它了。

[ [regexper](https://regexper.com/) ]是一个能让正则的备选状态可视化的工具，也有助于理解复杂的正则语法。

Regex 专题 03 —— 引擎


俗话说：有好米还要有好锅。正则表达式要真正发挥作用，要倚仗一些操作正则的方法。

咱们来看看JavaScript中都有哪些操作正则的方法。

## RegExp

`RegExp`是正则表达式的构造函数。

使用构造函数创建正则表达式有多种写法：

```javascript
new RegExp('abc');
// /abc/
new RegExp('abc', 'gi');
// /abc/gi
new RegExp(/abc/gi);
// /abc/gi
new RegExp(/abc/m, 'gi');
// /abc/gi
```

它接受两个参数：第一个参数是匹配模式，可以是字符串也可以是正则表达式；第二个参数是修饰符。

如果第一个参数的正则表达式定义了修饰符，第二个参数又有值，则以第二个参数定义的修饰符为准，这是ES2015的新特性。

使用构造函数一般用于需要动态构造正则表达式的场景，性能不如字面量写法。

我们来看看它的实例属性：

- lastIndex属性。它的作用是全局匹配时标记下一次匹配开始的位置，全局匹配的抓手就是它。
- source属性。它的作用是存储正则模式的主体。比如`/abc/gi`中的`abc`。
- 对应的修饰符属性。目前有`global`、`ignoreCase`、`multiline`、`sticky`、`dotAll`、`unicode`属性，返回布尔值表明是否开启对应修饰符。
- flags属性。返回所有的修饰符。

## match

`match`是String实例方法。

它的作用是根据参数返回匹配结果，取名match也是非常恰当了。

它接受一个正则表达式作为唯一参数。

可是字符串也可以作为参数怎么解释？

```javascript
'abc'.match('b');
// ["b", index: 1, input: "abc", groups: undefined]
```

这是因为match方法内部会隐式的调用`new RegExp()`将其转换成一个正则实例。

match方法的返回值可以分为三种情况。

#### 匹配失败

没什么可说的，返回`null`。

#### 非全局匹配

返回一个数组。

数组的第一项是匹配结果。如果不传参则匹配结果为空字符串。

```javascript
'abc'.match();
// ["", index: 0, input: "abc", groups: undefined]
```

如果正则参数中有捕获组，捕获的结果在数组中从第二项开始依次排列。有捕获组但是没有捕获内容则显示`undefined`。

```javascript
'@abc2018'.match(/@([a-z]+)([A-Z]+)?/);
// ["@abc", "abc", undefined, index: 0, input: "@abc2018", groups: undefined]
```

数组有一个`index`属性，标明匹配结果在文本中的起始位置。

数组有一个`input`属性，显示源文本。

数组有一个`groups`属性，它存储的不是捕获组的信息，而是捕获命名的信息。

```javascript
'@abc2018'.match(/@(?<lowerCase>[a-z]+)(?<upperCase>[A-Z]+)?/);
// ["@abc", "abc", undefined, index: 0, input: "@abc2018", groups: { lowerCase: "abc", upperCase: undefined }]
```

#### 全局匹配

返回一个数组。

捕获的若干结果在数组中依次排列。因为要返回所有匹配的结果，其他的信息，包括捕获组和若干属性就无法列出了。

```javascript
'abc&mno&xyz'.match(/[a-z]+/g);
// ["abc", "mno", "xyz"]
```

## replace

`replace`是String实例方法。

它的作用是将给定字符串替换匹配结果，并返回新的替换后的文本。源文本不会改变。

它接受两个参数。

第一个参数可以是字符串或者正则表达式，它的作用是匹配。

参数是字符串和参数是正则表达式的区别在于：正则表达式的表达能力更强，而且可以全局匹配。因此参数是字符串的话只能进行一次替换。

```javascript
'abc-xyz-abc'.replace('abc', 'biu');
// "biu-xyz-abc"
'abc-xyz-abc'.replace(/abc/, 'biu');
// "biu-xyz-abc"
'abc-xyz-abc'.replace(/abc/g, 'biu');
// "biu-xyz-biu"
```

第二个参数可以是字符串或者函数，它的作用是替换。

#### 第二个参数是字符串

replace方法为第二个参数是字符串的方式提供了一些特殊的变量，能满足一般需求。

`$数字`代表相应顺序的捕获组。注意，虽然它是一个变量，但是不要写成模板字符串\`${$1}biu\`，replace内部逻辑会自动解析字符串，提取出变量。

```javascript
'@abc-xyz-$abc'.replace(/([^-]+)abc/g, '$1biu');
// "@biu-xyz-$biu"
```

`$&`代表匹配结果。

```javascript
'@abc-xyz-$abc'.replace(/([^-]+)abc/g, '{$&}');
// "{@abc}-xyz-{$abc}"
```

$\`代表匹配结果左边的文本。

```javascript
'@abc-xyz-$abc'.replace(/([^-]+)abc/g, '{$`}');
// "{}-xyz-{@abc-xyz-}"
```

`$'`代表匹配结果右边的文本。

```javascript
'@abc-xyz-$abc'.replace(/([^-]+)abc/g, "{$'}");
// "{-xyz-$abc}-xyz-{}"
```

有些时候我要的是变量的符号本身，而不是它的变量值，怎么办？加一个`$`转义一下。

```javascript
'@abc-xyz-$abc'.replace(/([^-]+)abc/g, '$$1biu');
// "$1biu-xyz-$1biu"
'@abc-xyz-$abc'.replace(/([^-]+)abc/g, '$biu');
// "$biu-xyz-$biu"
'@abc-xyz-$abc'.replace(/([^-]+)abc/g, '$$biu');
// "$biu-xyz-$biu"
```

在不会造成误会的场景，一个`$`和两个`$`的效果都是一个`$`，因为另一个充当转义符号。会造成误会的场景，那就必须加`$`转义了。

#### 第二个参数是函数

字符串的变量毕竟只能引用，无法操作。与之相对，函数的表达能力就强多了。

函数的返回值就是要替换的内容。函数如果没有返回值，默认返回`undefined`，所以替换内容就是`undefined`。

函数的第一个参数，是匹配结果。

```javascript
'abc-xyz-abc'.replace(/abc/g, (match) => `{${match}}`);
// "{abc}-xyz-{abc}"
'abc-xyz-abc'.replace(/abc/g, (match) => {});
// "undefined-xyz-undefined"
```

如果有捕获组，函数的后顺位参数与捕获组一一对应。

```javascript
'@abc3-xyz-$abc5'.replace(/([^-]+)abc(\d+)/g, (match, $1, $2) => `{${$1}${match}${$2}}`);
// "{@@abc33}-xyz-{$$abc55}"
```

倒数第二个参数是匹配结果在文本中的位置。

```javascript
'@abc-xyz-$abc'.replace(/([^-]+)abc/g, (match, $1, index) => `{${match}是位置是${index}}`);
// "{@abc是位置是0}-xyz-{$abc是位置是9}"
```

倒数第一个参数是源文本。

```javascript
'abc-xyz'.replace(/abc/g, (match, index, string) => `{{${match}}属于{${string}}}`);
// "{{abc}属于{abc-xyz}}-xyz"
```

replace方法最常用的地方是转义HTML标签。

```javascript
'<p>hello regex</p>'.replace(/</g, '&lt;').replace(/>/g, '&gt;');
// "&lt;p&gt;hello regex&lt;/p&gt;"
```

## search

`search`是String实例方法。

它的作用是找出首次匹配项的索引。它的功能较单一，性能也更好。

它接受一个正则表达式作为唯一参数。与match一样，如果传入一个非正则表达式，它会调用`new RegExp()`将其转换成一个正则实例。

```javascript
'abc-xyz-abc'.search(/xyz/);
// 4
'abc-xyz-abc'.search(/xyz/g);
// 4
'abc-xyz-abc'.search(/mno/);
// -1
'abc-xyz-abc'.search();
// 0
'abc-xyz-abc'.search(/abc/);
// 0
```

因为只能返回首次匹配的位置，所以全局匹配对它无效。

如果匹配失败，返回`-1`。

## split

`split`是String实例方法。

它的作用是根据传入的分隔符切割源文本。它返回一个由被切割单元组成的数组。

它接受两个参数。第一个参数可以是字符串或者正则表达式，它是分隔符；第二个参数可选，限制返回数组的最大长度。

```javascript
'abc-def_mno+xyz'.split();
// ["abc-def_mno+xyz"]
'abc-def_mno+xyz'.split('-_+');
// ["abc-def_mno+xyz"]
'abc-def_mno+xyz'.split('');
// ["a", "b", "c", "-", "d", "e", "f", "_", "m", "n", "o", "+", "x", "y", "z"]
'abc-def_mno+xyz'.split(/[-_+]/);
// ["abc", "def", "mno", "xyz"]
'abc-def_mno+xyz'.split(/[-_+]/g);
// ["abc", "def", "mno", "xyz"]
'abc-def_mno+xyz'.split(/[-_+]/, 3);
// ["abc", "def", "mno"]
'abc-def_mno+xyz'.split(/[-_+]/, 5);
// ["abc", "def", "mno", "xyz"]
```

如果第一个参数传入的是空字符串，则会切割每一个字符串。

另外，因为split方法中的正则是用来匹配分隔符，所以全局匹配没有意义。

## exec

`exec`是RegExp实例方法。

它的作用是根据参数返回匹配结果，与字符串方法match相似。

```javascript
/xyz/.exec('abc-xyz-abc');
// ["xyz", index: 4, input: "abc-xyz-abc", groups: undefined]
/mno/.exec('abc-xyz-abc');
// null
/xyz/.exec();
// null
```

小小的区别在于参数为空的情况：exec直接返回`null`；match返回一个空字符串数组。原因也很好理解，有鱼没有网，最坏也就是没有收成；有网没有鱼，那可是连奔头都没有了。

它们俩最大的区别在于全局匹配的场景。

全局匹配就意味着多次匹配，RegExp实例有一个`lastIndex`属性，每匹配一次，这个属性就会更新为下一次匹配开始的位置。exec就是根据这个属性来实现全局匹配的。

```javascript
const reg = /abc/g;
reg.lastIndex
// 0
reg.exec('abc-xyz-abc');
// ["abc", index: 0, input: "abc-xyz-abc", groups: undefined]
reg.lastIndex
// 3
reg.exec('abc-xyz-abc');
// ["abc", index: 8, input: "abc-xyz-abc", groups: undefined]
reg.lastIndex
// 11
reg.exec('abc-xyz-abc');
// null
reg.lastIndex
// 0
reg.exec('abc-xyz-abc');
// ["abc", index: 0, input: "abc-xyz-abc", groups: undefined]
```

如果有多个匹配结果，多次执行就能获得所有的匹配结果。所以exec一般用在循环语句中。

有两点需要特别注意：

- 因为`lastIndex`会不断更新，最终又会归于0，所以这个匹配过程是可以无限重复的。
- `lastIndex`属性是属于正则实例的。只有同一个实例的`lastIndex`才会不断更新。

知道第二点意味着什么吗？

```javascript
/abc/g.exec('abc-xyz-abc');
// ["abc", index: 0, input: "abc-xyz-abc", groups: undefined]
/abc/g.exec('abc-xyz-abc');
// ["abc", index: 0, input: "abc-xyz-abc", groups: undefined]
/abc/g.exec('abc-xyz-abc');
// ["abc", index: 0, input: "abc-xyz-abc", groups: undefined]
// ...
```

如果不把正则提取出来，获得它的引用，exec方法就一直在原地打转，因为每次都是一个新的正则实例，每次`lastIndex`都要从0开始。

## test

`test`是RegExp实例方法。

它的作用是找出源文本是否有匹配项，与字符串方法search相似。多用于表单验证中。

```javascript
/abc/.test('abc-xyz-abc');
// true
/mno/.test('abc-xyz-abc');
// false
/abc/.test();
// false
```

test方法与search方法的区别主要体现在两点：

- search方法返回的是索引，test方法只返回布尔值。
- 因为是正则实例方法，全局匹配时也会更新正则实例的`lastIndex`属性，所以也可以多次执行。

```javascript
const reg = /abc/g;
reg.lastIndex
// 0
reg.test('abc-xyz-abc');
// true
reg.lastIndex
// 3
reg.test('abc-xyz-abc');
// true
reg.lastIndex
// 11
reg.test('abc-xyz-abc');
// false
reg.lastIndex
// 0
reg.test('abc-xyz-abc');
// true
```

## 修改字符串方法的底层实现

我们也看到了，一部分处理正则的方法定义在String实例上，一部分处理正则的方法定义在RegExp实例上。为了将处理正则的方法全部统一到RegExp实例上，ES2015修改了部分字符串方法的底层实现。

具体来说，ES2015为RegExp实例新增了四个方法，字符串方法`match`、`replace`、`search`、`split`内部调用已经改成了相应的RegExp实例方法。

```javascript
RegExp.prototype[Symbol.match]
RegExp.prototype[Symbol.replace]
RegExp.prototype[Symbol.search]
RegExp.prototype[Symbol.split]
```

`Symbol.match`是什么？`Symbol`是新增的一种基础数据类型，它有11个内置的值，指向语言内部使用的方法。

`RegExp.prototype[Symbol.match]`在使用上和`match`相比，调用者和参数翻转一下就可以了。

```javascript
'abc-mno-xyz'.match(/mno/);
// ["mno", index: 4, input: "abc-mno-xyz", groups: undefined]
/mno/[Symbol.match]('abc-mno-xyz');
// ["mno", index: 4, input: "abc-mno-xyz", groups: undefined]
```

Regex 专题 02 —— 方法

Regex 专题 01 —— 语法


关于Redux的扩展能力，大家说的最多的是中间件，但是为什么createStore的第三个参数叫enhancer呢？

其实enhancer是一个比中间件更加底层的接口。

applyMiddleware就是Redux官方的enhancer。

## 增强器

 enhancer翻译成中文是增强器。如果说中间件是在dispatch前后植入一段逻辑的话，那么增强器顾名思义是要增强整个Store的能力。很明显它的侵入性更强。

我们以applyMiddleware为例来讲解增强器的特点。

```javascript
export default function applyMiddleware(...middlewares) {
    return createStore => (...args) => {
        const store = createStore(...args);
        let dispatch = () => {
            throw new Error(
                `Dispatching while constructing your middleware is not allowed. ` +
                `Other middleware would not be applied to this dispatch.`
            );
        };
        const middlewareAPI = {
            getState: store.getState,
            dispatch: (...args) => dispatch(...args),
        };
        const chain = middlewares.map(middleware => middleware(middlewareAPI));
        dispatch = compose(...chain)(store.dispatch);
        return { ...store, dispatch };
    }
}
```

applyMiddleware方法执行以后被传入createStore方法，这个时候它依然是一个函数，接受一个唯一的参数createStore。

为什么要将createStore以参数传进来呢？因为applyMiddleware内部要生成一个Store，而生成一个Store的目的是为了保留其余API，替换dispatch API。

> 如果说中间件改造的是dispatch，那么增强器改造的就是Store。

## compose

假如Redux需要用到两个以上的增强器怎么办？

关键时候，还得老将出马。

compose在createStore内部出现过一次，其实低调的它还是Redux的顶级API。

用在哪里，当然是组合若干增强器啦。

```javascript
const enhancer = compose(applyMiddleware(middleware1, middleware2, middleware3), enhancer2, enhancer1);
const store = createStore(reducer, preloadedState, enhancer);
```

大家有没有发现一个惊天秘密？

传入多个中间件不需要compose组合，而传入多个增强器需要compose组合。

这是因为，applyMiddleware我们上一章讲过，源码内部就有一个compose，所以就不再需要了。

## 时间旅行

大家可能用过Git，也可能没用过。

Git最大的本事是可以还原任意版本的仓库，某种意义上这是不是一个时间机器？

现在我给时间机器加上两个限制条件：

- 它只能回溯过去。
- 它只能观测，不能修改历史。

Redux版本的时间机器就是这种阉割版的时间机器。

状态追溯的前提是什么？

状态追溯的前提是不修改状态，这样才能保存时间线上的所有状态，然后在需要的时候回放。

现在知道Reducer为什么每次都要返回一个新对象的原因了吧。

实际上Redux的作者Dan Abramov一开始设计Redux就是奔着时间旅行去的，所以Redux才会有这么多繁琐的步骤。

## 使用

想要启用时间旅行来调试Redux，市面上有两种方式。

#### 浏览器扩展

首先，从Chrome下载扩展Redux DevTools。

它会暴露一个全局API，之前是`window.devToolsExtension`，现在变成了`window.__REDUX_DEVTOOLS_EXTENSION__`。目的是让全局属性更不容易被覆盖。

如果应用不需要安装其他中间件和增强器，那么这样写就可以了：

```javascript
import { createStore } from 'redux';
import reducer from './reducer';

const store = createStore(reducer, window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__());

export default store;
```

否则这样写：

```javascript
import { createStore, applyMiddleware, compose } from 'redux';
import reducer from './reducer';
import middlewares from './middlewares';

const composeEnhancers = window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ || compose;
const store = createStore(reducer, composeEnhancers(applyMiddleware(...middlewares)));

export default store;
```

`window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__`是浏览器扩展暴露的另一个全局API。

还没结束，浏览器扩展的作者仍然担心你觉得繁琐，所以又提供了一个npm包。

先来看不需要安装其他中间件和增强器的场景：

```javascript
import { createStore } from 'redux';
import { devToolsEnhancer } from 'redux-devtools-extension';
import reducer from './reducer';

const store = createStore(reducer, devToolsEnhancer());

export default store;
```

否则这样写：

```javascript
import { createStore, applyMiddleware } from 'redux';
import { composeWithDevTools } from 'redux-devtools-extension';
import reducer from './reducer';
import middlewares from './middlewares';

const store = createStore(reducer, composeWithDevTools(applyMiddleware(...middlewares)));

export default store;
```

#### 非浏览器扩展

首先，浏览器扩展和非浏览器扩展的实现方式是不一样的，不要混为一谈。

`redux-devtools-dock-monitor`的作用是让你可以随意控制时间旅行的面板，props中传入的各种key都是键盘的快捷键。

`redux-devtools-log-monitor`的作用是在面板上显示历史状态，没有它`redux-devtools`就是个空壳子。

```javascript
import { createDevTools } from 'redux-devtools';
import DockMonitor from 'redux-devtools-dock-monitor';
import LogMonitor from 'redux-devtools-log-monitor';
import reducer from './reducer';
import middlewares from './middlewares';

const DevTools = createDevTools(
    <DockMonitor toggleVisibilityKey='ctrl-h' changePositionKey='ctrl-q' defaultIsVisible={true}>
        <LogMonitor theme='tomorrow' />
    </DockMonitor>
);

const store = createStore(reducer, compose(applyMiddleware(...middlewares), DevTools.instrument()));
```

如果不需要这么花哨，也可以不安装`redux-devtools-dock-monitor`：

```javascript
const DevTools = createDevTools(<LogMonitor />);
```

什么也不传入行不行？

不行，createDevTools必须得有一个children。

```javascript
export default function createDevTools(children) {
    const monitorElement = Children.only(children);
    // ...
}
```

#### 界面

如果是浏览器扩展的方式，在Chrome DevTools面板会增加一个Redux菜单，点击即可看到调试面板。

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/redux/image/01.png)

如果是非浏览器扩展的方式，界面是内嵌在网页中的：

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/redux/image/02.png)

不好意思，图中并没有时间旅行的进度条。因为要显示进度条，得安装另外的npm包。

```javascript
import { createDevTools } from 'redux-devtools';
import SliderMonitor from 'redux-slider-monitor';

const DevTools = createDevTools(<SliderMonitor />);
```

然后效果就是这样的：

![illustration](https://raw.githubusercontent.com/veedrin/horseshoe/master/redux/image/03.png)

所以呀，浏览器扩展其实是将各种模块都集成到一起，打包成一个解决方案。

## 文献

这是一个瑞典人的开源项目，分别用两种方式写的demo，可以立刻查看效果。

[基于浏览器扩展的Redux时间旅行demo](https://argelius.github.io/react-onsenui-redux-weather/)

[不基于浏览器扩展的Redux时间旅行demo](https://argelius.github.io/react-redux-timetravel/)


Redux 专题 04 —— 时间旅行


Redux暴露非常少的API，优雅的将单向数据流落地。但有这些，Redux的作者Dan Abramov仍然觉得远远不够。一个工具的强大之处体现在它的扩展能力上。Redux的中间件机制让这种扩展能力同样变的异常优雅。

中间件在前端的意思是插入某两个流程之间的一段逻辑。具体到Redux，就是在dispatch一个动作前后插入第三方的处理函数。

## 使用

还记得吗？Store构造器createStore有三个参数，第三个参数叫做`enhancer`，翻译过来就是增强器。我们先将enhancer按下不表，并且告诉你其实Redux的另一个API`applyMiddleware`就是一个enhancer。

```javascript
import { createStore, combineReducers, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
import logger from 'redux-logger';
import { userReducer } from './user/reducer';
import { todoReducer } from './todo/reducer';

const reducers = combineReducers({
    userStore: userReducer,
    todoStore: todoReducer,
});

const enhancer = applyMiddleware(thunk, logger);
const store = createStore(reducers, null, enhancer);

export default store;
```

只需要把所有中间件依次传入applyMiddleware，就生成了一个增强器，它们就可以发挥作用了。

如果preloadedState为空，enhancer可以作为第二个参数传入。看源代码：

```javascript
if (typeof preloadedState === 'function' && typeof enhancer === 'undefined') {
    enhancer = preloadedState;
    preloadedState = undefined;
}

if (typeof enhancer !== 'undefined') {
    if (typeof enhancer !== 'function') {
        throw new Error('Expected the enhancer to be a function.');
    }
    return enhancer(createStore)(reducer, preloadedState);
}

if (typeof reducer !== 'function') {
    throw new Error('Expected the reducer to be a function.');
}
```

## 服务器请求

一个组件免不了向服务器请求数据，然而开发者不希望组件内部有过多的逻辑，请求应该封装成函数给组件调用，同时组件需要实时获取请求的状态以便展示不同的界面。最好的办法就是将请求也纳入Redux的管理中。

```javascript
import api from './api';

export const fetchMovieAction = () => {
    dispatch({ type: 'FETCH_MOVIE_START' });
    api.fetchMovie().then(res => {
        dispatch({ type: 'FETCH_MOVIE_END', payload: { movies: res.data } });
    }).catch(err => {
        dispatch({ type: 'FETCH_MOVIE_ERROR', error: true, payload: { msg: err } });
    });
};
```

```javascript
import React, { Component } from 'react';
import { connect } from 'react-redux';

import { fetchMovieAction } from './actions';
import Card from './Card';

class App extends Component {
    render() {
        const { movies } = this.props;
        return (
            <div className="movie">
                {movies.map(movie => <Card key={movie.id} {...movies} />)}
            </div>
        );
    }

    componentDidMount() {
        this.props.fetchMovie();
    }
}

const mapState = (state) => {
    return {
        movies: state.payload.movies,
    };
};

const mapDispatch = (dispatch) => {
    return {
        fetchMovie: () => dispatch(fetchMovieAction()),
    };
};

export default connect(mapState, mapDispatch)(App);

```

大功告成了。

只需要将请求封装成一个函数，然后伪装成Action被发射出去，请求调用前后，真正的Action会被发射，在Store中存储请求的状态，并且能够被组件订阅到。

#### 异步Action

你是不是发现了什么？对咯，这里的Action不是一个纯对象。

因为请求一定是一个函数，为了让请求入会，只能反过头来修改大会章程。但是大会章程岂能随便推翻，这时意见领袖出来说话了：

> 当初规定Action必须是一个纯对象不是为了搞个人崇拜，而是出于实际需要。因为reducer必须是一个纯函数，这决定了dispatch的参数Action必须是一个带type字段的纯对象。现如今我们要拉异步请求入会，而中间件又可以中途拦截做一些处理，那Action为什么不能是一个函数呢？`Action必须是一个纯对象`这种说法是完完全全的教条主义！

大家还动脑筋想出了一个异步Action的名头，这下函数类型的Action终于名正言顺了。

#### 闭包

你是不是还发现了什么？对咯，请求函数中的dispatch哪去了。

不知道，可能会报错吧(无辜脸)。

其实我们还有一件事没干：把dispatch方法偷渡到请求函数中。

```javascript
export const fetchMovieAction = () => {
    return (dispatch) => {
        dispatch({ type: 'FETCH_MOVIE_START' });
        api.fetchMovie().then(res => {
            dispatch({ type: 'FETCH_MOVIE_END', payload: { movies: res.data } });
        }).catch(err => {
            dispatch({ type: 'FETCH_MOVIE_ERROR', error: true, payload: { msg: err } });
        });
    };
};
```

很简单哪，加一个闭包，dispatch从返回函数的参数中偷渡进来。

#### 脑洞

我们要的不就是一个dispatch方法么，我能不能这样：

```javascript
export const fetchMovie = (dispatch) => {
    dispatch({ type: 'FETCH_MOVIE_START' });
    api.fetchMovie().then(res => {
        dispatch({ type: 'FETCH_MOVIE_END', payload: { movies: res.data } });
    }).catch(err => {
        dispatch({ type: 'FETCH_MOVIE_ERROR', error: true, payload: { msg: err } });
    });
};
```

```javascript
const mapDispatch = (dispatch) => {
    return {
        fetchMovie: () => fetchMovie(dispatch),
    };
};
```

貌似是能行得通的，只不过这时候请求函数已经不能叫Action了。考虑到之前请求函数伪装成Action浑水摸鱼，还要插入中间件来帮助特殊处理，我们这样做也不过分是吧。

好处就是不再需要能够处理异步Action的中间件了。

坏处就是这不符合规范，是我的脑洞，闯了祸不要打我(蔑视)。

## redux-thunk

前面多次提到处理异步Action的中间件，到底是何方神圣？

市面上流行的方案有很多种，我们挑最简单的一种来说一说(都不点赞怪我咯)。

`redux-thunk`算是Redux官方出品的异步请求中间件，但是它没有集成到Redux中，原因还是为了扩展性，社区可以提出各种方案，开发者各取所需。

让我们来探讨一下redux-thunk的思路：原来Action只有一种，就是纯对象，现在Action有两种，纯对象和异步请求函数。只不过多了一种情况，不算棘手嘛。如果Action是一个对象，不为难它直接放走；如果Action是一个函数，就地执行，调用异步请求前后，真正的Action自然会释放出来，又回到第一步，放它走。

这是redux-thunk简化后的代码，其实源代码也跟这差不多。是不是很恐慌？

```javascript
const thunk = ({ dispatch, getState }) => next => action => {
    if (typeof action === 'function') {
        return action(dispatch, getState);
    }
    return next(action);
};
```

上面的函数就部署在我的个人博客中用来处理异步请求，完全没有问题。既然它这么简单，而且可以预计它万年不会变，那我为什么要凭空多一个依赖包。就将它放在我的眼皮底下不是挺好的嘛。

不过，它是一个研究中间件很好的范本。

我们先将thunk先生降级成普通函数的写法：

```javascript
const thunk = function({ dispatch, getState }) {
    return function(next) {
        return function(action) {
            if (typeof action === 'function') {
                return action(dispatch, getState);
            }
            return next(action);
        }
    }
};
```

## compose

我知道`compose`是Redux的五大护法之一，可为什么挑在这个时候讲它呢？

先不告诉你。

compose在函数式编程中的含义是组合。假如你有一堆函数要依次执行，而且上一个函数的返回结果是下一个函数的参数，我们怎样写看起来最装逼？

```javascript
const result = a(b(c(d(e('redux')))));
```

这种写法让人一眼就看穿了调用细节，装逼明显是不够的。

我们来看Redux是怎么实现compose的：

```javascript
export default function compose(...funcs) {
    if (funcs.length === 0) {
        return arg => arg;
    }
    if (funcs.length === 1) {
        return funcs[0];
    }
    return funcs.reduce((a, b) => (...args) => a(b(...args)));
}
```

诶，我看见reduce了，然后...就没有然后了。

假设我们现在有三个函数：

```javascript
const funcA = arg => console.log('funcA', arg);
const funcB = arg => console.log('funcB', arg);
const funcC = arg => console.log('funcC', arg);
```

执行reduce的第一步返回的accumulator(accumulator是reduce中的概念)，结果显而易见：

```javascript
(...args) => funcA(funcB(...args));
```

执行reduce的第二步返回的accumulator，注意到，这时reduce已经执行完了，返回的是一个函数。

```javascript
(...args) => funcA(funcB(funcC(...args)));
```

特别提醒：执行compose最终返回的是一个函数。也就是说开发者得这么干`compose(a, b, c)()`才能让传入的函数依次执行。

另外需要注意的是：传入的函数是从右到左依次执行的。

## applyMiddleware

废话少说，先上源代码：

```javascript
export default function applyMiddleware(...middlewares) {
    return createStore => (...args) => {
        const store = createStore(...args);
        let dispatch = () => {
            throw new Error(
                `Dispatching while constructing your middleware is not allowed. ` +
                `Other middleware would not be applied to this dispatch.`
            );
        };
        const middlewareAPI = {
            getState: store.getState,
            dispatch: (...args) => dispatch(...args),
        };
        const chain = middlewares.map(middleware => middleware(middlewareAPI));
        dispatch = compose(...chain)(store.dispatch);
        return { ...store, dispatch };
    }
}
```

还记得中间件闭包好几层的写法吗？现在我们就来一层一层的剥开它。

`middlewareAPI`是一个对象，正好是传给第一层中间件函数的参数。执行它，返回的chain是由第二层函数组成的中间件数组。贴一下redux-thunk第二层转正后的样子：

```javascript
function(next) {
    return function(action) {
        if (typeof action === 'function') {
            return action(dispatch, getState);
        }
        return next(action);
    }
}
```

中间件第二层函数接收一个next参数，那这个next具体指什么呢？我先透露一下，next是整个Redux中间件机制的题眼，理解了next就可以对Redux中间件的理解达到大彻大悟的化境。

之前我们已经拆解了compose的内部机制，从右到左执行，最右边的中间件的参数就是`store.dispatch`，它返回的值就是倒数第二个中间件的next。它返回什么呢？我们再剥一层：

```javascript
function(action) {
    if (typeof action === 'function') {
        return action(dispatch, getState);
    }
    return next(action);
}
```

别看redux-thunk麻雀虽小，大家发现没有，第三层函数才是它的逻辑，前面两层都是配合redux的演出。也就是说呀同学们，除了最后一个中间件的next是原始的dispatch之外，倒数往前的中间件传入的next都是上一个中间件的逻辑函数。

> Redux中间件本质上是将dispatch套上一层自己的逻辑。

最终applyMiddleware里得到的这个dispatch是经过无数中间件精心包装，植入了自己的逻辑的dispatch。然后用这个臃肿的dispatch覆盖原有的dispatch，将Store的API返回。

每一个Action就是这样穿过重重的逻辑代码才能最后被发射成功。只不过处理异步请求的中间件不再往下走，直到异步请求发生，真正的Action被发射出来，才会走到下一个中间件的逻辑。

#### 构建dispatch过程中禁止执行dispatch

middlewareAPI中的dispatch为什么是一个抛出错误的函数？

我们现在已经知道，applyMiddleware的目的只有一个：用所有中间件组装成一个超级dispatch，并将它覆盖原生的dispatch。但是如果超级dispatch还没组装完成，就被中间件调用了原生的dispatch，那这游戏别玩了。

所以Redux来了一手掉包。

middlewareAPI初始传入的dispatch是一个炸弹，中间件的开发者胆敢在头两层闭包函数的外层作用域调用dispatch，炸弹就会引爆。而一旦超级dispatch构建完成，这个超级dispatch就会替换掉炸弹。

怎么替换呢？

函数也是引用类型对吧，炸弹dispatch之所以用`let`定义，就是为了将来修改它的引用地址：

```javascript
let dispatch = () => {
    throw new Error(
        `Dispatching while constructing your middleware is not allowed. ` +
        `Other middleware would not be applied to this dispatch.`
    );
};
// ...
dispatch = compose(...chain)(store.dispatch);
```

当然，这是对中间件开发者的约束，如果你只是一个中间件的使用者，这无关紧要。

#### applyMiddleware的花式调用

我们注意到，执行applyMiddleware返回的是一个函数，这个函数有唯一的参数createStore。

WTF？

applyMiddleware不是createStore的参数之一么：

```javascript
const store = createStore(reducer, applyMiddleware(middleware1, middleware2, middleware3));
```

怎么createStore也成了applyMiddleware的参数了？

贵圈真乱。

首先我们明确一点，applyMiddleware是一个增强器，增强器是需要改造Store的API的，这样才能达到增强Store的目的。所以applyMiddleware必须传入createStore以生成初始的Store。

所以生成一个最终的Store其实可以这样写：

```javascript
const enhancedCreateStore = applyMiddleware(middleware1, middleware2, middleware3)(createStore);
const store = enhancedCreateStore(reducer);
```

那通常的那种写法，Redux内部是怎么处理的呢？

```javascript
if (typeof enhancer !== 'undefined') {
    if (typeof enhancer !== 'function') {
        throw new Error('Expected the enhancer to be a function.')
    }
    return enhancer(createStore)(reducer, preloadedState)
}
```

上面是createStore源代码中的一段。

如果enhancer存在并且是一个函数，那么直接传入createStore执行，再传入reducer和preloadedState执行(这时候再传入enhancer就没完没了了)，然后直接返回。

喵，后面还有好多代码呢，怎么就返回了？

不，就这么任性。

这么看下来，以下写法才是正宗的Redux：

```javascript
const store = applyMiddleware(middleware1, middleware2, middleware3)(createStore)(reducer);
```

以下写法只是Redux为开发者准备的语法糖：

```javascript
const store = createStore(reducer, applyMiddleware(middleware1, middleware2, middleware3));
```

## 洋葱圈模型

想必大家都听说过中间件的洋葱圈模型，这个比喻非常形象，乍听上去，啊，好像明白了。但是大家真的对洋葱圈模型有一个具象化的理解吗？

假设现在有三个中间件：

```javascript
const middleware1 = ({ dispatch, getState }) => next => action => {
    console.log('middleware1 start');
    next(action);
    console.log('middleware1 end');
}

const middleware2 = ({ dispatch, getState }) => next => action => {
    console.log('middleware2 start');
    next(action);
    console.log('middleware2 end');
}

const middleware3 = ({ dispatch, getState }) => next => action => {
    console.log('middleware3 start');
    next(action);
    console.log('middleware3 end');
}
```

现在将它传入applyMiddleware：

```javascript
function reducer(state = {}, action) {
    console.log('reducer return state');
    return state;
}

const middlewares = [middleware1, middleware2, middleware3];
const store = createStore(reducer, applyMiddleware(...middlewares));
```

我们看一下打印的结果：

```
middleware1 start
middleware2 start
middleware3 start
reducer return state
middleware3 end
middleware2 end
middleware1 end
```

对结果感到惊讶吗？其实理解函数调用栈的同学就能明白为什么是这样的结果。reducer执行之前也就是dispatch真正执行之前的日志好理解，dispatch被一层一层包装，一层一层的深入调用。但是dispatch执行完以后呢？这时候的执行权在调用栈最深的那一层逻辑那里，也就是最接近原始dispatch的逻辑函数那里，所以之后的执行顺序是从最深处往上调用。

总的看下来，一个Action的更新Store之旅就像穿过一个洋葱圈的旅行。一堆中间件簇拥着Action钻到洋葱的中心，Action执行自己的使命更新Store后就地圆寂，然后中间件带着它的遗志再从洋葱的中心钻出来。

#### 回看compose

其实我解释上面的打印日志，还有一个关节没有打通。

记得applyMiddleware的源代码吗？内部调用了compose来执行chain。

我们强调过，compose的函数类型参数的执行顺序是从右到左的，我相信大家在不少的地方都见到过这样的表述。但是大家想过没有，为什么要从右到左执行？原生JavaScript除了实现reduce之外还有一个reduceRight，从左到右执行并没有什么技术障碍，那么为什么要让执行顺序这么别扭呢？

答案就在上面的打印日志里。

打印日志很好哇，根据传入的顺序执行。对，执行compose是从右到左，但是compose返回的终极dispatch是一层一层从外面包裹的呀，最后一个中间件也就是最左边的中间件的逻辑，包裹在最外面一层，自然它的日志最先被打印出来。

所以compose被设计成参数从右到左执行，不是有技术障碍，也不是Redux特立独行，而是其中本来就要经历一次反转，compose只有再反转一次才能将它扭转过来。

Redux 专题 03 —— 中间件


Redux是一套精巧而实用的工具，这也是它在开发者中如此流行的原因。

所以对待Redux，最重要的就是熟练使用它的主要API，一旦将它了然于胸，就会对Redux的设计思想有一个全局的认识，也就能清楚的判断自己的应用需不需要劳驾Redux出手。

需要注意：咱们默认将Redux和React搭配使用，不过Redux不是非得和它在一起的。

## Action

要达成某个目的，开发者首先要描述自己的意图。Action就是用来描述开发者意图的。它不是一个函数，而是一个普通的对象，通过声明的类型来触发相应的动作。

我们来看一个例子：

```javascript
{
    type: 'ADD_TODO_ITEM',
    payload: {
        content: '每周看一本书',
        done: false,
    },
}
```

Redux官方定义了字段的一些规范：一个Action必须包含`type`字段，同时一个Action包含的字段不应该超过`type`、`payload`、`error`、`meta`这四种。

- type声明Action的类型。一般用全大写的字符串表示，多个字母用下划线分隔。
- payload在英文中的意思是`有效载荷`。引申到程序中就是有效字段的意思，也就是说真正用于构建应用的信息都应该放到payload字段里。
- error字段并不承载错误信息，而是一个出错的token。只有当值为true时才表示出错，值为其他或者干脆没有该字段表示程序运行正常。那么错误信息放哪呢？当然是放payload里面，因为错误信息也属于构建应用的有效信息。
- meta在英文中的意思是`元`。在这里表示除了payload之外的信息。

因为意图是通过类型来定义的，所以type字段必不可少，称某个对象为一个Action的标志就是它有一个type字段。

除此之外，一个动作可能包含更为丰富的信息。开发者可以随意添加字段，毕竟它就是个普通对象。不过遵守一定的规范便于其他开发者阅读你的代码，可以提升协作效率。

#### Constants

前面说了type字段一般用全大写的字符串表示，多个字母用下划线分隔。不仅如此，大家还有一个约定俗成：用一个结构相同的变量保存该字符串，因为它会在多处用到。

```javascript
const ADD_TODO_ITEM = 'ADD_TODO_ITEM';
```

集中保存这些变量的文件就叫`Constants.js`。

在此，我提出一点异议。如果你觉得不麻烦，那遵循规范再好不过。但开发者向来觉得Redux过于繁琐，如果你也这么觉得，大可不必维护所谓的Constants。维护Constants的好处不过是一处更改处处生效，然而字符串和变量是结构相同的，如果字符串作了修改，语意上必然大打折扣，况且type字段一旦定义极少更改，所以视你的协作规模和个人喜好而定，为Redux的繁琐减负不是么？

#### Action Creators

我们知道Action是一个对象，但是如果多次用到这个对象，我们可以写一个生成Action的函数。

```javascript
function addTodoItem(content) {
    return {
        type: ADD_TODO_ITEM,
        payload: { content, done: false },
    };
}
```

同理，如果你觉得繁琐，这一步是可以免去的。

异步场景下Action Creators会大有用处，后面会讲到。

需要注意的是：所谓的Action更确切的说是一个执行动作的指令，而不是一个动作。或者我们换一种说法，这里的动作指的是动作描述，而不是动作派发。

## Store

Redux的本质不复杂，就是用一个全局的外部的对象来存储状态，然后通过观察者模式来构建一套状态更新触发通知的机制。

这里的Store就是存储状态的容器。

但是呢？它需要开发者动手写一套逻辑来指导它怎么处理状态的更新，这就是后面要讲的Reducer，暂且按下不表。

问题是Store怎么接收这套逻辑呢？

```javascript
import { createStore } from 'redux';

import reducer from './reducer';

const store = createStore(reducer);
```

看到没有，Redux专门有一个API用来创建Store，它接受三个参数：`reducer`、`preloadedState`和`enhancer`。

reducer就是处理状态更新的逻辑。

preloadedState是初始状态，如果你需要让Store一开始不是空对象，那么可以从这里传进去。

enhancer翻译成中文是`增强器`，是用来装载第三方插件以增强Redux的功能的。

#### 怎么存

我们已经了解了Action的作用，但是Action只是对动作的描述，怎么说它得有个发射器吧。这个发射器就隐藏在Store里。

执行`createStore`返回的对象包含了一个函数`dispatch`，传入Action执行就会发射一个动作。

```javascript
import React, { Component } from 'react';
import store from './store';
import action from './action';

class App extends Component {
    render() {
        return (
            <button onClick={() => store.dispatch(action)}>dispatch</button>
        );
    }
}

export default App;
```

#### 怎么取

好了我们已经发射了一个动作，假设现在Store中已经有状态了，我们怎么把它取出来呢？

直接`store.xxx`么？

我们先来打印Store这个对象看看：

```javascript
{
    dispatch: ƒ dispatch(action),
    getState: ƒ getState(),
    replaceReducer: ƒ replaceReducer(nextReducer),
    subscribe: ƒ subscribe(listener),
    Symbol(observable): ƒ observable(),
}
```

打印出来一堆API，这可咋整？

别着急，茫茫人海中看到一个叫`getState`的东西，它就是我们要找的高人吧。插一句，大家注意区分Store和State的区别，Store是存储State的容器。

Redux隐藏了Store的内部细节，所以开发者只能用getState来获取状态。

#### 订阅

Redux是基于观察者模式的，所以它开放了一个订阅的API给开发者，每次发射一个动作，传入订阅器的回调都会执行。通过它开发者就能监听动作的派发以执行相应的逻辑。

```javascript
import store from './store';

store.subscribe(() => console.log('有一个动作被发射了'));
```

#### replaceReducer

顾名思义，替换Reducer，这主要是方便开发者调试Redux用的。

## Reducer

Reducer是Redux的核心概念，因为Redux的作者Dan Abramov这样解释`Redux`这个名字的由来：Reducer+Flux。

其实Reducer是一个计算机术语，包括JavaScript中也有用于迭代的`reduce`函数。所以我们先来聊聊应该怎样理解Reducer这个概念。

reduce翻译成中文是`减少`，Reducer在计算机中的含义是归并，也是化多为少的意思。

我们来看JavaScript中reduce的写法：

```javascript
const array = [1, 2, 3, 4, 5];
const sum = array.reduce((total, num) => total + num);
```

再来看Redux中Reducer的写法：

```javascript
function todoReducer(state = [], action) {
    switch (action.type) {
        case 'ADD_TODO_ITEM':
            const { content, done } = action.payload;
            return [...state, { content, done }];
        case 'REMOVE_TODO_ITEM':
            const todos = state.filter(todo => todo.content !== action.content);
            return todos;
        default:
            return state;
    }
}
```

state参数是一个旧数据集合，action中包含的payload是一个新的数据项，Reducer要做的就是将新的数据项和旧数据集合归并到一起，返回给Store。这样看起来Reducer这个名字起的也没那么晦涩了是不是？

一个Reducer接受两个参数，第一个参数是旧的state，我们返回的数据就是用来替换它的，然后风水轮流转，这次返回的数据下次就变成旧的state了，如此往复；第二个参数是我们派发的action。

因为Reducer的结构类似，都是根据Action的类型返回相应的数据，所以一般采用`switch case`语句，如果没有变动则返回旧的state，总之它必须有返回值。

#### 纯函数

Reducer的作用是归并，也只能是归并，所以Redux规定它必须是一个纯函数。相同的输入必须返回相同的输出，而且不能对外产生副作用。

所以开发者在返回数据的时候不能直接修改原有的state，而是应该在拷贝的副本之上再做修改。

#### 多个Reducer

一个Reducer只应该处理一个动作，可是我们的应用不可能只有一个动作，所以一个典型的Redux应用会有很多Reducer函数。那么怎么管理这些Reducer呢？

首先来看只有一个Reducer的情况：

```javascript
import { createStore } from 'redux';

import reducer from './reducer';

const store = createStore(reducer);

export default store;
```

如果只有一个Reducer，那我们只需要将它传入`createStore`这个函数中，就这么简单。这时候Reducer返回的状态就是Store中的全部状态。

而如果有多个Reducer，我们就要动用Redux的另一个API了：`combineReducers`。

```javascript
const reducers = combineReducers({
    userStore: userReducer,
    todoStore: todoReducer,
});
```

当我们有多个Reducer，就意味着有多个状态需要交给Store管理，我们就需要子容器来存储它们，其实就是对象嵌套对象的意思。combineReducers就是用来干这个的，它把每一个Reducer分门别类的与不同的子容器对应起来，某个Reducer只处理对应的状态。

```javascript
{
    userStore: {},
    todoStore: {},
};
```

当我们用getState获取整个Store的状态，返回的对象就是上面这样的。

你猜对了，传入combineReducers的对象的key就是子容器的名字。

#### 默认值

当开发者调用createStore创建Store时，传入的所有Reducer都会执行一遍。注意，这时开发者还没有发射任何动作呢，那为什么会执行一遍？

```javascript
const randomString = () => Math.random().toString(36).substring(7).split('').join('.');

const ActionTypes = {
    INIT: `@@redux/INIT${randomString()}`,
    REPLACE: `@@redux/REPLACE${randomString()}`,
    PROBE_UNKNOWN_ACTION: () => `@@redux/PROBE_UNKNOWN_ACTION${randomString()}`
};

dispatch({ type: ActionTypes.INIT });
```

因为Redux源码中，在createStore函数里面放了这样一段逻辑，这初始化时的dispatch是Redux自己发射的。

为什么？

还记得Reducer接受两个参数吗？第一个是state，而我们可以给state设置默认值。

聪明的你一定想到了，初始化Store时Redux自己发射一个动作的目的是为了收集这些默认值。Reducer会将这些默认值返回给Store，这样默认值就保存到Store中了。

聪明的你大概还想到一个问题：createStore也有默认值，Reducer也有默认值，不会打架么？

Redux的规矩：createStore的默认值优先级更高，所以不会打架。

#### 执行

在一个有若干Reducer的应用中，一个动作是怎么找到对应的Reducer的？

这是一个好问题，答案是挨个找。

假如应用有1000个Reducer，与某个动作对应的Reducer又恰好在最后一个，那要把1000个Reducer都执行一遍，Redux不会这么傻吧？

Redux还真就这么傻。

因为当一个动作被派发时，Redux并不知道应该由哪个Reducer来处理，所以只能让每个Reducer都处理一遍，看看到底是谁的菜。可不可以在设计上将动作与Reducer对应起来呢？当然是可以的，但是Redux为了保证API的简洁和优美，决定牺牲这一部分性能。

只是一些纯函数而已，莫慌。

## react-redux

当我们使用Redux时，我们希望每发射一个动作，应用的状态自动发生改变，从而触发页面的重新渲染。

```javascript
import React, { Component } from 'react';
import store from './store';

class App extends Component {
    state = { name: 'Redux' };

    render() {
        const { name } = this.state;
        return (
            <div>{name}</div>
        );
    }

    componentDidMount() {
        this.unsubscribe = store.subscribe(() => {
            const { name } = store.getState();
            this.setState({ name });
        });
    }

    componentWillUnmount() {
        this.unsubscribe();
    }
}
```

怎么办呢？开发者得手动维护一个订阅器，才能监听到状态变化，从而触发页面重新渲染。

但是React最佳实践告诉我们，一个负责渲染UI的组件不应该有太多的逻辑，那么有没有更好的办法使得开发者可以少写一点逻辑，同时让组件更加优雅呢？

别担心，Redux早就帮开发者做好了，不过它是一个独立的模块：`react-redux`。顾名思义，这个模块的作用是连接React和Redux。

#### Provider

连接React和Redux的第一步是什么呢？当然是将Store集成到React组件中，这样我们就不用每次在组件代码中`import store`了。多亏了React context的存在，Redux只需要将Store传入根组件，所有子组件就能通过某种方式获取传入的Store。

```javascript
import React from 'react';
import ReactDOM from 'react-dom';
import { Provider } from 'react-redux';

import store from './store';

import App from './App';

ReactDOM.render(
    <Provider store={store}>
        <App />
    </Provider>
    ,
    document.getElementById('root')
);
```

#### connect

老式的context写法，在子组件中定义`contextTypes`就可以接收到传入的参数。当然，你肯定也想到，Redux把这些细节都封装好了，这就是`connect`。

connect接口的意义主要有三点：

- 封装用context从根组件获取数据的细节。
- 封装Redux订阅器的细节。
- 作为一个容器组件真正连接React和Redux。

```javascript
import React from 'react';
import Todo from './Todo';

const App = ({ todos, addTodoItem }) => {
    return (
        <div>
            <button onClick={() => addTodoItem()}>add</button>
            {todos.map(todo => <Todo key={todo.id} {...todo} />)}
        </div>
    );
}

const mapStateToProps = (state, ownProps) => {
    return {
        todos: state.todoStore,
    };
};

const mapDispatchToProps = (dispatch, ownProps) => {
    return {
        addTodoItem: (todoItem) => dispatch({ type: 'ADD_TODO_ITEM', payload: todoItem }),
    };
};

export default connect(mapStateToProps, mapDispatchToProps)(App);
```

我们看上面例子，connect接受的两个参数：`mapStateToProps`和`mapDispatchToProps`，所谓的map就是映射，意思就是将所有state和dispatch依次映射到props上。如此真正的组件需要的数据和功能都在props上，它就可以安安心心的做一个傻瓜组件。

connect接受四个参数：

- mapStateToProps。也可以写成mapState，这个参数是用来接收订阅得到的数据更新的，也就是说如果这个参数传null或者undefined，则被connect包裹的组件无法收到更新的数据。mapStateToProps必须是一个函数，而且必须返回一个纯对象。它接收两个参数，第一个参数是存储在Store中完整的state，第二个参数是被connect包裹的组件自身的属性。假如App组件挂载时写成这样：`<App value={value} />`，那么ownProps就是一个包含value的对象。
- mapDispatchToProps。也可以写成mapDispatch，这个参数是用来封装所有发射器的。mapDispatchToProps必须是一个函数，而且必须返回一个纯对象。它接收两个参数，第一个参数是dispatch发射器函数，第二个参数和mapStateToProps的第二个参数相同。
- mergeProps。顾名思义，合并props。现在被connect包裹的组件拥有三种props：由state转化而来的props，由dispatch转化而来的props，自身的props。它返回的纯对象就是最终组件能接收到的props。默认返回的对象是用`Object.assign()`合并上述三种props。
- options。用来自定义connect的选项。

我们注意到，connect要先执行一次，返回的结果再次执行才传入开发者定义的组件。它返回一个新的组件，这个新的组件不会修改原组件(除非你操纵了ownProps的返回)，而是为组件增加一些新的props。

我们也可以用装饰器写法来重写connect：

```javascript
import React from 'react';
import Todo from './Todo';

const mapStateToProps = (state, ownProps) => {
    return {
        todos: state.todoStore,
    };
};

const mapDispatchToProps = (dispatch, ownProps) => {
    return {
        addTodoItem: (todoItem) => dispatch({ type: 'ADD_TODO_ITEM', payload: todoItem }),
    };
};

@connect(mapStateToProps, mapDispatchToProps)
const App = ({ todos, addTodoItem }) => {
    return (
        <div>
            <button onClick={() => addTodoItem()}>add</button>
            {todos.map(todo => <Todo key={todo.id} {...todo} />)}
        </div>
    );
}

export default App;
```

## 总结

Redux通过调用createStore返回Store，它是一个独立于应用的全局对象，通过观察者模式能让应用监听到Store中状态的变化。最佳实践是一个应用只有一个Store。

Redux必须通过一个明确的动作来修改Store中的状态，描述动作的是一个纯对象，必须有type字段，传递动作的是Store的属性方法dispatch。

Store本身并没有任何处理状态更新的逻辑，所有逻辑都要通过Reducer传递进来，Reducer必须是一个纯函数，没有任何副作用。如果有多个Reducer，则需要利用combineReducers定义相应的子状态容器。

基于容器组件和展示组件分离的设计原则，也为了提高开发者的编程效率，Redux通过一个额外的模块将React和Redux连接起来，使得所有的状态管理接口都映射到组件的props上。其中，Provider将Store注入应用的根组件，解决的是连接的充分条件；connect将需要用到的state和dispatch都映射到组件的props上，解决的是连接的必要条件。只有被Provider包裹的组件，才能使用connect包裹。

Redux 专题 02 —— 实用


React的横空出世给前端带来一场革命。其实随React一同开源的还有一个叫Flux的东西。Flux是管理应用状态的一种架构。光凭一个props是无法实现血缘关系疏远的组件之间的状态同步的。虽然context加回调可以勉强做到这一点，但是Flux架构有其更加深远的意义。

你看，从一开始facebook的工程师就知道只凭React无法支撑大型的应用开发。但是为什么称Flux为一种架构而不是一个类库或者框架呢？因为它的出现主要是为了提出一种思想，而不是作为一个真正成熟的类库。facebook的工程师希望社区根据这种思想涌现出多样化的实现方式。

那么，Flux提出的思想是什么呢？

这一切还要从MVC架构说起。

## MVC

以前端举例，MVC架构将一个应用分为`Model` 、`View`和 `Controller`三部分。`Model` 代表数据模型，用来存放业务逻辑；`View`代表视图，是最终的界面效果；`Controller`代表控制器，响应用户的操作。

一个用户操作`View`发出指令，`Controller`处理该指令并且将处理结果传递给`Model`，`Model`再将更新后的数据渲染到`View`上。

当一个应用越来越复杂时，如何去维护庞大的代码和让新人快速的上手就变的紧迫起来。MVC架构的分层思想就是服务于这一目的，它并不能让应用的性能提升，但是它可以让代码对开发者更友好。不过影响代码对开发者友好度的可不止这一点，更重要的是数据的流向在开发者面前的清晰度。

MVC架构有没有对数据的流向做很好的控制呢？并没有。它有一套理想中的流程，就是上面讲到的视图更新的操作过程，然而`View`可不可以直接给`Model`发指令？当然可以，并且很多开发者就是这么做的。如果每一层都可以和每一层通信，代码的可读性将变的混乱不堪。

## Flux

Flux就是为解决这个问题而生的。MVC架构的问题在于没有严格控制数据的流向，所以facebook的工程师将Flux设计成数据只能走单通道，一个特定的操作才能触发另一个特定的操作。

一个Flux应用包含四部分：

- `Action`，一个动作对象，相当于用户的指令。
- `Dispatcher`，处理动作的派发，相当于MVC架构的`Controller`。
- `Store`，负责存储数据，相当于MVC架构的`Model`。
- `View`，和MVC架构一样。

用户触发`View`上的事件发送`Action`，`Action`只能通过`Dispatcher.dispatch`方法发送出去，`Store`更新自身的数据然后`View`根据`Store`重新渲染。一环扣一环，只能按照这个流程走下去。

这就是我们说的单向数据流。

至此，我们实现了功能的分层和数据的单向流动，代码不再那么混乱了。

## Redux

我们的主角是Redux，它也是目前React社区最受欢迎的状态管理框架。实际上，Redux就是Flux的门徒之一。它如此受欢迎，一定是因为它在Flux的基础上做对了什么事情。

Flux解决了单向数据流的问题，那么Redux解决了什么问题呢？

我认为Redux的贡献主要是这两点：

- 推崇唯一数据源。
- 加入函数式编程思想。`状态只读`和`只能通过纯函数来改变状态`都是函数式编程的特性，目的就是为了改变状态的过程中不产生副作用。

咱们先来说说唯一数据源是怎么回事？

Flux的设计是将每一块相对独立的状态分别用一个Store来存储。这样的好处是显而易见的，每一个Store的体积都足够小，对象的嵌套不会很深。

坏处是什么呢？

Dispatcher在派发动作的时候，会依次访问每一个Store。这样虽然会损失一些性能，但是Dispatcher的逻辑可以做到极简，它不用知道这个动作应该派发给谁，都给它们发一遍得了。假如Store A对Store B存在依赖关系，那么它们的状态更新顺序就很重要，而Dispatcher哪管这些个儿女情长。于是开发者需要通过Dispatcher注册回调函数返回的token来手动管理Store之间的依赖关系。

这无疑又是对开发者不友好的设计。

所以Redux干脆，只维护一个全局的Store，让你开发者再哔哔哔。正事不干，就知道哔哔哔。

需要注意的是，Redux并没有从机制上阻止开发者使用多个Store管理应用，开发者还是可以作妖的。不过这又回到Flux的老路上去了，对开发者一点好处都没有。Redux选择用思想和约定来约束开发者。

再来说函数式编程。

函数式编程思想的提出最早是为了处理复杂的计算任务。计算任务的要求是什么呢？结果可预期，任务之间不会相互影响。

相同的输入，总是有相同的输出。对应到函数，就是不能修改已有的数据，只要修改已有的数据，理论上就有可能输出不同的结果。那么我确实有修改数据的需求怎么办？生成一个新的衍生数据。

执行某个任务不会对外部产生影响，也就是所谓的没有副作用。

我们想一下，Redux加入函数式编程思想的目的不还是为了让单项数据流更加清晰和单纯么？

Redux给前端带来的另一个重大成果是时间旅行式的调试。开发者可以回到任意时间点的案发现场，看看那个臭虫到底是哪个阴沟里生出来的。

如果你看完本专题，就会发现Redux的作者Dan Abramov从一开始设计Redux就是奔着时间旅行式的调试去的。时间旅行才是Redux写法这么繁琐的罪魁祸首。

所以Flux的历史功绩是为前端引入了一种思想，而Redux仅仅是改进这种思想而已，还算不上一代宗师。不过Redux本来就是Flux的门徒之一，作为门徒能够将师门发扬光大也是一代豪杰了。

Redux 专题 01 —— 考古


所有的UI都是树形结构，大节点嵌套小节点。于是React开发人员开始想，既然它们有这些共性，能不能把它们抽象出来呢？

于是就有了所谓的`Virtual DOM`，但我更愿意称它为抽象UI。抽象比虚拟更加触及精髓，因为DOM是一个只存在于网页中的概念。

## 对象

一个节点就是一个对象，对象之间的嵌套关系对应于DOM节点之间的嵌套关系。

这个对象要描述哪些关键信息呢？

- 节点类型。
- 节点属性。注意，子节点也是属性之一。
- 服务于React自身的信息。

下面是一个节点的对象表示法。

```javascript
{
    $$typeof: Symbol(react.element),
    key: null,
    props: {
        children: Object || Array,
    },
    ref: null,
    type: 'div',
    _owner: {
        alternate: {},
        child: {},
        effectTag: 5,
        expirationTime: 0,
        firstEffect: null,
        index: 0,
        key: null,
        lastEffect: null,
        memoizedProps: null,
        memoizedState: null,
        mode: 0,
        nextEffect: null,
        pendingProps: null,
    },
}
```

## diff

有了抽象UI，那么组件挂载的过程究竟是怎样的呢？

首先呢，初次挂载的时候肯定是把抽象UI编译成DOM标签，然后插入到`container`当中。

没错，React再通天，最终也是要使用`innerHTML`来挂载DOM 的。

```javascript
const setInnerHTML = createMicrosoftUnsafeLocalFunction(function(node, html) {
    node.innerHTML = html;
});
```

然后呢，每当有state或props更新，再将抽象UI编译一次，插入到`container`当中。

当然不是这样的啦！

React怎么可能跟我们写的过家家代码一样呢。

初始挂载的时候，React确实是会使用`innerHTML`接口，但是一旦挂载完毕，后续的更新都是打补丁，也就是精准的局部更新。

打补丁就涉及到两个问题：

- 如何知道在哪里打补丁？
- 打补丁的频率。

这就要说到抽象UI的diff算法。

当React决定来一波更新的时候，它会生成一套新的抽象UI树。注意，这时候React手里有两套抽象UI树了，通过对比这两棵树，React就能知道哪里产生了变化。

按照常识，假如某棵树的某个父节点由div换成了ul，但是子节点没有任何变化，那我们只需要修改该父节点的类型即可。因为只有这里变了，这才是打补丁的正确方式。

但是我们要考虑另一个问题：比较的过程所花的时间。

实现上述常识操作的算法复杂度是O(n^3)，因为要递归比较。也就是说如果抽象UI树非常庞大，那以JavaScript的尿性是吃不消的，页面会出现卡顿。

所以React不得不做一些妥协。只比较同级的节点可以让算法复杂度降低到O(n)，相对来讲，是一个比较好的折中方案。那么上面的例子，一旦父节点由div换成了ul，那么React就会简单粗暴的替换掉所有子节点。

每次setState都会触发diff算法吗？

当然不会。因为不是真正的UI，所以React可以控制它的更新频率，这样也可以提升性能。

React生命周期大致可以分为三个阶段：挂载，更新，卸载。在挂载阶段内和一次更新阶段内，diff算法只会运行一次，这就是打补丁的频率。

这也是人们说setState是异步的原因。

#### 两种变化类型

现在我们知道，React只会对同一层级的节点进行比较。

那么就会产生三种结果：没有变化，节点类型改变（或者同时节点属性），节点类型不变节点属性改变。

没有变化是最好的，早点收工。

节点类型改变，比如说div变成了ul，那么不再检查属性，直接替换。同时所有的子节点也要替换。当然如果新的抽象UI树没有对应的节点，那就意味着删除了。

节点类型不变节点属性改变，那么DOM树结构不变，只是对该节点的属性做一些增删改操作。

#### 列表

上面说到，React会依次对同一层级的节点进行比较，如果类型不同则重新挂载节点，如果类型相同属性不同则更新节点。

我们来看看列表，如果我给一个列表`unshift`一项，可以想象，React在比较列表的每一项时，结果都是类型相同属性不同，于是需要更新列表的每一项。但其实我们只是往列表插入一项而已，原生写法只需要`insertBefore`就好了。

算法不能太复杂，有没有什么其他的办法呢？

如果给列表的每一项加一个唯一标识符，React在比较的时候就能知道某一项不是被去掉了，而是换了位置。也就能学会插入操作了。

所以开发者在使用`map`方法渲染列表时，都会要求给列表每一项加一个唯一的key属性，它就是让React变得更聪明的脑白金。

```javascript
import React from 'react';

const App = ({ list }) => {
    return (
        <div>
            {list.map(v => <div key={v}>{v}</div>)}
        </div>
    );
}

export default App;
```

有人问了：我不用`map`方法渲染，手动写一个列表，React打算怎么处理？

不处理！

你想，`map`方法渲染的列表是数据映射出来的，开发者很容易操作数组。但是在JSX中手动写一个列表，首先不推荐大家这样做(吃力不讨好)，其次大家很少会在React中操作DOM，所以你也不能把这个列表玩出花来。最重要的，React没办法识别这是一个列表。

还有一点，React不推荐使用列表的索引来充当key属性值，因为对列表进行插入或者删除操作时，索引也会相应的改变，它是不稳定的，key存在的意义也就没有了。

但是有些时候我们实在找不到唯一的稳定的某个值，那就只能用索引来搪塞了。

那意思React是说：孩子，不为难你了，早点下班吧。

## Fiber

一般的显示器刷新频率都是60Hz。这是什么意思呢？意味着屏幕画面每秒刷新60次，或者大约每16.7ms屏幕画面刷新一次。这是人眼比较舒服的频率。

对网页而言，亦是如此。

这意味着如果JavaScript计算任务连续占用浏览器主线程超过16.7ms，网页就没办法做到60Hz的刷新率，结果就是我们常说的页面卡顿甚至白屏。

一般来说，只要不陷入死循环或者太深的调用栈，JavaScript可以从容的执行，甚至大概率还有剩余时间，行到水穷处，坐看云起时。

偏偏哪，React优化性能的机制是依靠大量的JavaScript计算。如果是一个大型的项目，组件可能会有上百层的嵌套，这个调用栈之深可想而知。

所以为了更加平滑的体验，React开发组闭关两年，祭出了Fiber这个大杀器。

可以把Fiber理解为虚拟调用栈。计算机术语中除了进程(Process)、线程(Thread)，还有纤程(Fiber)，React就是取其更精密的并发控制之意。

React这个开源项目大体上可以分为两部分，一部分是构建抽象UI，并提供变化检测，叫Reconciler。另一部分是将抽象UI渲染到具体的平台上，叫Renderer。

Reconciler的主要工作是计算，Renderer的主要工作是排版和绘制。

首先，要将Reconciler拆分成更小的事务，再将这些事务从用户体验的角度划分优先级，从而可以实现更细微的调度，而不是像之前一口气跑完。至于排版和绘制，那本来就是平滑体验的关键，去打断它没有任何意义。

#### 调度工具

接下来就轮到大佬上场了。

`requestAnimationFrame`API：刀耕火种时期的前端想要写动画，得用`setTimeout`或者`setInterval`来触发一些定时动作。首先，如果定时器执行频率比屏幕刷新率高，有一些动作可能会被忽略，浏览器直接渲染下一个动作去了。这就是定时器与屏幕刷新步调不一致导致的丢帧。还有，定时器是异步任务，如果主线程被占用它就只能眼巴巴的等着。而`requestAnimationFrame`从名字就能看出来，它是为动画而生的，杀手锏是浏览器会保证它的执行频率和屏幕刷新率一致(如果有空余时间的话)，就是那种被大佬罩着的人。优先级比较高。

`requestIdleCallback`API：这个接口更有意思，它会告诉开发者，在16.7ms之内，浏览器把活干完还剩下多少时间，然后把剩下时间的控制权交给开发者。当然如果浏览器自己都不够用，你就喝汤吧。所以它不保证一定会执行，行就行，不行就拉倒。

React就是通过这两个API来实现事务的调度的。

Reconciler从一个风风火火的意气少年变成了一个小心翼翼的中年男人，每执行一小段事务就探出头来看看，浏览器当前有没有高优先级的事务在排队啊？如果有赶紧让开啊，等浏览器处理完咱们再偷偷的进村啊。

#### 对生命周期的影响

我们说生命周期分为挂载、更新和卸载，生命周期从另一个角度又可以分为render前和render后。

之所以这样划分是因为React本身有Reconciler和Renderer两部分，现在的问题在哪呢？

因为Reconciler现在是可以打断的，也就是说render前的生命周期钩子有可能被执行多次，而且它的表现是没办法预测的，因为是否被打断要依据当时的情况。

这也就是componentWillMount、componentWillReceiveProps和componentWillUpdate生命周期钩子要被逐步替换掉的原因。

React 专题 09 —— 抽象UI


React存在的意义就是状态与UI分离，使开发者不知有DOM，无论魏晋。

不过有些状态是无法与UI分离的，比如说表单的聚焦，复杂的动画等等。

怎么办？在React完全控制DOM之前，它还是给开发者留了后门。

## this.refs

> 💀这是React不再推荐使用的API。

每一个class组件实例化的时候都会挂载一个refs属性，它就是用来存储DOM引用的。

在DOM元素上传入一个值是字符串的`ref`属性，开发者就获得了该DOM元素的引用，我们可以在`this.refs`对象下面找到它。

既然是获取DOM元素的引用，那肯定要等组件挂载完成才能操作它。

不过React已经不推荐这种写法。主要是它比较耗性能，因为UI会经历很多次更新，而字符串引用无法自动跟踪DOM的变化，React要做一些额外的处理。

也许将来某个版本我们就看不到实例的refs属性了。

```javascript
import React, { Component } from 'react';

class App extends Component {
    componentDidMount() {
        this.refs.textInput.focus();
    }
    
    render() {
        return (
            <input type="text" ref="textInput" />
        );
    }
}

export default App;
```

## callback

React还支持用一个回调接收DOM元素的引用。

但是记住，回调不可以写成`el => this.refs.textInput = el`，因为`this.refs`是不可以直接进行写操作的。

```javascript
import React, { Component } from 'react';

class App extends Component {
    componentDidMount() {
        this.textInput.focus();
    }
    
    render() {
        return (
            <input type="text" ref={el => this.textInput = el} />
        );
    }
}

export default App;
```

当然，回调神通广大，比如说，它会穿墙术。

依然是使用回调接收DOM元素的引用，不过这次的回调是父组件通过props传下来的。

一旦子组件挂载完成，就会执行ref回调，父组件就得到子组件某个DOM元素的引用了。

```javascript
import React, { Component } from 'react';
import Search from './Search';

class App extends Component {
    getInputRef = (ref) => {
        this.node = ref;
    }
    
    render() {
        return (
            <Search ref={this.getInputRef} />
        );
    }
}

export default App;
```

```javascript
import React from 'react';

const Search = (props) => (
    <input type="text" ref={props.getInputRef} />
);

export default Search;
```

## createRef

> 👽这是React v16.3.0发布的API。

`createRef`的作用就是创建一个ref对象。

先把`createRef`的执行结果返回给一个实例属性，然后通过该实例属性获得DOM元素的引用。

注意事项：

- `createRef`初始化动作要在组件挂载之前，如果是挂载之后初始化，则无法得到DOM元素的引用。
- 真正的DOM元素引用在current属性上。

```javascript
import React, { Component, createRef } from 'react';

class App extends Component {
    textInput = createRef();

    componentDidMount() {
        this.textInput.current.focus();
    }

    render() {
        return (
            <input type="text" ref={this.textInput} />
        );
    }
}

export default App;
```

出于不可描述的原因，如果你想获取一个子组件的ref引用，那么子组件必须是class组件。

因为你获取的实际上是子组件的实例，而函数式组件是没有实例的。

所有获取ref引用的方式，如果想要获取子组件而不是DOM元素，子组件都不能是函数式组件。

```javascript
import React, { Component, createRef } from 'react';
import Child from './Child';

class App extends Component {
    childRef = createRef();

    render() {
        return (
            <Child ref={this.childRef} />
        );
    }
}

export default App;
```

## forwardRef

> 👽这是React v16.3.0发布的API。

使用回调可以获取子组件的DOM元素引用，不过这种技巧终究是hack。

所以贴心的React为我们提供了一个会穿墙术的武林正派。

父组件的写法并没有什么特别，只不过这次`createRef`返回的结果不是传给自己的某个DOM元素，而是子组件。

关键在于子组件，子组件把自己整个作为参数传给了`forwardRef`，然后子组件就在props参数之外，获得了ref参数，再把ref参数赋值给某个DOM元素的ref属性。

发现了吗？`forwardRef`充当的是一个传递者的角色，它实际上是一个容器组件。

向前传递，这就是叫`forwardRef`的原因。

需要特别注意，使用`forwardRef`时，该组件必须是函数式组件。原因可能是React不想破坏class组件的参数体系。

诶，前面不是说了获取组件的ref引用时不能使用函数式组件么？

仔细看，两者是有本质区别的，这里获取的依然是DOM元素，只不过跨级了。

```javascript
import React, { Component, createRef } from 'react';
import Search from './Search';

class App extends Component {
    textInput = createRef();

    componentDidMount() {
        this.textInput.current.focus();
    }

    render() {
        return (
            <Search ref={this.textInput} />
        );
    }
}

export default App;
```

```javascript
import React, { forwardRef } from 'react';

const Search = forwardRef((props, ref) => (
    <input type="text" ref={ref} />
));

export default Search;
```

既然跨级，能不能玩大点？

当然可以。

事实上，一旦被`forwardRef`包裹的子组件接收到了ref参数，它可以继续将ref往下传递。通过什么传递，当然是props啦！

之后ref就变成了一个普通的props，任你差遣，直到它被挂载到某个DOM元素的ref属性上。

发现没有，再往下就不区分class组件和函数式组件了，因为class组件和函数式组件都可以接收props。它的任务只是帮某个不知道多少代的祖先把这个特定的prop挂载到特定的DOM元素上。

其实ref回调也是可以跨多级传递的，原理同上。

```javascript
import React, { Component, createRef } from 'react';
import Search from './Search';

class App extends Component {
    textInput = createRef();

    render() {
        return (
            <Search ref={this.textInput} />
        );
    }
}

export default App;
```

```javascript
import React from 'react';
import Input from './Input';

const Search = forwardRef((props, ref) => (
    <Input inputRef={ref} />
));

export default Search;
```

```javascript
import React, { Component } from 'react';

class Input extends Component {
    render() {
        return (
            <input type="text" ref={this.props.inputRef} />
        );
    }
}

export default Input;
```

React 专题 08 —— 操作DOM


用户需要与UI产生交互，所以UI需要一个反应机制，用户执行特定操作，就触发特定的回调函数，开发者再把这个机制挂载到DOM元素上。

DOM事件开发者再熟悉不过了，没了它页面就是死的。

那么React的事件机制有什么特殊吗？

不夸张的说，React是一个UI虚拟机一样的存在，在被挂载到页面上之前，UI在React的全权掌控下。React会干出什么来谁也说不准。

让我们来看看React对DOM事件机制做了什么手脚。

## 事件委托

事件委托我们都知道，因为有冒泡机制，开发者可以在父级元素监听事件，通过逻辑判断使得只有子元素的事件才会触发监听回调，这样就实现了子元素的事件监听委托给父元素。

在前端刀耕火种时期，事件委托解决了两个痛点。

- 处理庞大的列表时，无需为每个列表项绑定事件监听。
- 动态挂载的元素无需作额外的事件监听处理。

可以看到，事件委托的红利主要是性能提升，大量重复的事件监听可以交由一个事件监听统一分发。

这样的好处，React会不要？

不过，React做的更彻底。

一个React应用只有一个事件监听器，这个监听器挂载在`document`上。你没听错，就是这么粗暴。所有的事件都由这个监听器统一分发。

组件挂载和更新时，会将绑定的事件分门别类的放进一个叫做`EventPluginHub`的事件池里。事件触发时，根据事件产生的`Event`对象找到触发事件的组件，再通过组件标识和事件类型从事件池里找到对应的事件监听回调，然后就是打个响指。

原生DOM事件系统会为每个事件生成一个`Event`对象，你去打印出来看看，这玩意有多少属性。所以React一不做二不休，基于`Event`对象创建了一个合成事件对象。它能解决什么问题呢？

- 它能实现跨浏览器的表现一致性，因为React做了很多兼容性的处理。兼容性问题是前端的毒瘤啊。
- 如果事件多次触发，合成事件对象会被复用，提高性能。

一般来说，当元素被卸载，元素绑定的事件监听器也要清除。要不然JavaScript放个`removeEventListener`接口出来干什么？

因为React实现了对事件的统一管理，所以这些脏活累活都自动帮你干了，你不需要手动清除JSX上绑定的事件监听器。这同时也可以提高性能，因为开发者多半会忘记清除。当然原生事件React就无能为力了。

说到原生事件，React合成事件与原生事件是什么关系呢？

答案是没有关系，互不干扰。

以下例子，即便阻止了冒泡，点击按钮依然会同时触发document事件。放心，不是兼容性的问题。合成事件拥有独立的冒泡机制，它只能阻止顶层的合成事件。

```javascript
import React, { Component } from 'react';

class App extends Component {
    render() {
        return (
            <button onClick={this.handleClick}>Click</button>
        );
    }
    
    componentDidMount() {
        document.addEventListener('click', (event) => console.log(event));
    }
    
    handleClick = (event) => {
        event.stopPropagation();
        console.log(event);
    }
}

export default App;
```

React知道你事多，所以在合成事件对象下面保存了原生事件对象`nativeEvent`，以备不时之需。

```javascript
import React, { Component } from 'react';

class App extends Component {
    render() {
        return (
            <button onClick={this.handleClick}>Click</button>
        );
    }
    
    componentDidMount() {
        document.addEventListener('click', (event) => console.log(event));
    }
    
    handleClick = (event) => {
        event.nativeEvent.stopPropagation();
        console.log(event);
    }
}

export default App;
```

哈？你说还是不行？

莫不是你计算机坏了，听我一句劝，砸了吧。

别慌别慌，这里还有一个知识点：

原生事件对象里除了`stopPropagation`之外还有`stopImmediatePropagation`(是不是从来没用过)，有什么区别？

`stopImmediatePropagation`不仅会阻止顶层事件的冒泡，连自身元素绑定的其他事件也会阻止。因为同一个元素可以绑定多个事件，而事件触发顺序是根据绑定顺序来的，只要使用了这个方法，它之后绑定的兄弟事件也别想蹦跶了。

那这跟React有什么关系呢？

你忘了？上面讲到，React有一套合成事件机制，所有事件都由document统一分发。

所以呀，别看这俩一个在button上，一个在document上，其实它们都是在document上触发的。

这下理解了为什么要用`stopImmediatePropagation`阻止冒泡了吧，它们是曹丕和曹植啊。

```javascript
import React, { Component } from 'react';

class App extends Component {
    render() {
        return (
            <button onClick={this.handleClick}>Click</button>
        );
    }
    
    componentDidMount() {
        document.addEventListener('click', (event) => console.log(event));
    }
    
    handleClick = (event) => {
        event.nativeEvent.stopImmediatePropagation();
        console.log(event);
    }
}

export default App;
```

不信再看一个衍生例子。

这回`stopImmediatePropagation`不仅不能阻止body事件，body事件还会先于button触发。铁证，React所有事件都是由document统一分发的。

```javascript
import React, { Component } from 'react';

class App extends Component {
    render() {
        return (
            <button onClick={this.handleClick}>Click</button>
        );
    }
    
    componentDidMount() {
        document.body.addEventListener('click', (event) => console.log(event));
    }
    
    handleClick = (event) => {
        event.nativeEvent.stopImmediatePropagation();
        console.log(event);
    }
}

export default App;
```

#### 合成事件的异步处理

先来看例子，大家觉得最终state里的value是什么？

答案是程序崩溃。

别看了，没有语法错误。

报错信息里说`Cannot read property 'value' of null`，说明target为空，问题是target怎么会为空呢？

症结就在于React追求极致的性能。在合成事件机制里，一旦事件监听回调被执行，合成事件对象就会被销毁，而setState的回调是异步的，等它执行的时候合成事件对象早就被销毁了。这就是target为空的原因。

```javascript
import React, { Component } from 'react';

class App extends Component {
    render() {
        return (
            <button onClick={this.handleClick}>Click</button>
        );
    }
    
    handleClick = (event) => {
        this.setState((prevState) => ({ value: event.target.value }));
    }
}

export default App;
```

如果实在有这样的需求，React也有锦囊妙计：`event.persist()`。

这就是告诉React，你别回收了，我还要拿去钓妹子呢。

```javascript
import React, { Component } from 'react';

class App extends Component {
    render() {
        return (
            <button onClick={this.handleClick}>Click</button>
        );
    }
    
    handleClick = (event) => {
        event.persist();
        this.setState((prevState) => ({ value: event.target.value }));
    }
}

export default App;
```

我们再来看一种情况。

卧槽，怎么又可以了？我啥也没跟React说呀。

我们都说setState是异步(或者说批量更新)的，那是说渲染异步，而赋值给value是同步的。

所以这个时候value是有值的。

那为什么回调形式的setState得不到值呢？回调嘛，你想嘛，是同步还是异步。

```javascript
import React, { Component } from 'react';

class App extends Component {
    render() {
        return (
            <button onClick={this.handleClick}>Click</button>
        );
    }
    
    handleClick = (event) => {
        this.setState({ value: event.target.value });
    }
}

export default App;
```

## 绑定this

鬼知道JavaScript里的this干倒了多少人。

其实，要弄清楚this的指向，只要找到调用者就行了。调用者，就是this的题眼。

为什么例子中的函数在非严格模式下指向window，而在严格模式下指向undefined呢？

因为在JavaScript刀耕火种时代，window既是窗口对象，也是全局对象。而所有的全局变量（包括函数）都挂载在window下面。

非严格模式下这个函数的调用者就是window。

后面人们觉得这样太八路军了，甚至有人觉得这是JavaScript最大的设计失误。所以之后的严格模式、class类和ESModule的全局变量都不再挂载到window上，反正能找补一点是一点。

所以严格模式下这个函数没有调用者，或者叫神之调用，所以this指向undefined。

```javascript
function something() {
    console.log(this);
}
```

科普了一下this，我们来看看this在React中有什么幺蛾子。

(假装)我们都知道，下面例子的this打印出来是undefined。

关键是为什么？

```javascript
import React, { Component } from 'react';

class App extends Component {
    render() {
        return (
            <button onClick={this.handleClick}>Click</button>
        );
    }
    
    handleClick() {
        console.log(this);
    }
}

export default App;
```

先看一个别的例子。

obj.something是一个函数，action也是一个函数，区别在于调用者。一个函数一旦被重新赋值，它的调用者就可能发生变化。

```javascript
const obj = {
    something: function() {
        console.log(this);
    },
};
obj.something(); // 打印obj

const action = obj.something;
action(); // (假设严格模式)打印undefined
```

再回到之前的例子，关键在这一句`onClick={this.handleClick}`，注意回调已经被重新赋值了，不管将来它的调用者是谁，这时它已经和组件实例无关了。

然后，我们要知道，React会把同一类型的事件push到一个队列里，一旦document监听到这类事件，就会依次执行队列里的回调，直到冒泡被阻止。

就像这样`[handleDivClick, handleButtonClick]`，想象一下被这样处理之后，执行时调用者是谁。

这就是上面例子打印出来是undefined的原因。

其实React早期版本，程序会自动绑定this到组件实例，但是有人觉得这样会使部分开发者以为this指向组件实例就是理所应当的，所以取消了这一操作。

于是呢，开发者要手动绑定this。我们来看看绑定this的花样。

#### 在JSX里面直接绑定this

简单粗暴对吧。再怎么狸猫换太子，我都绑的死死的。

不过呢，bind的性能是堪忧的。而且你发现没有，每一次重新render都会重新bind一次。

```javascript
import React, { Component } from 'react';

class App extends Component {
    render() {
        return (
            <button onClick={this.handleClick.bind(this)}>Click</button>
        );
    }
    
    handleClick() {
        console.log(this);
    }
}

export default App;
```

#### 包裹一层箭头函数

箭头函数会继承父作用域的this，这里的父作用域当然就是组件实例。

可是得额外包裹一层箭头函数，而且每次触发事件都会生成一个箭头函数。

当然事件需要传参的时候没的说，必须得包裹一层箭头函数。

```javascript
import React, { Component } from 'react';

class App extends Component {
    render() {
        return (
            <button onClick={() => this.handleClick()}>Click</button>
        );
    }

    handleClick() {
        console.log(this);
    }
}

export default App;
```

#### 在构造函数里手动绑定

这也是React官方推荐的写法。

此写法的意思是：把一个绑定了this的回调赋值给实例的属性。

缺点是如果事件比较多，构造函数里会有点拥挤。

而且往深层处想，这个回调被挂载在了原型上，同时也被挂载在了实例上。重复挂载。

```javascript
import React, { Component } from 'react';

class App extends Component {
    constructor(props) {
        super(props);
        this.handleClick = this.handleClick.bind(this);
    }
    
    render() {
        return (
            <button onClick={this.handleClick}>Click</button>
        );
    }
    
    handleClick() {
        console.log(this);
    }
}

export default App;
```

#### 回调直接写在实例上

这种写法叫做属性初始化器(Property Initializers)。目前还不是JavaScript正式的语法，不过babel可以提前让开发者使用。

首先说明，该写法的关键不是直接写在实例上，而是箭头函数。因为箭头函数会继承父作用域的this，所以回调中的this指向组件实例。

不信你把箭头函数改成匿名函数试试。

那我能不能把箭头函数写在原型上呢？你甭管我用什么办法。

也是可以的，只是有点麻烦。

属性初始化器的写法不会将回调重复挂载，不需要重复绑定，语法也相当优雅。

等成为了JavaScript正式的语法，React官方一定会推荐这种写法的。

```javascript
import React, { Component } from 'react';

class App extends Component {
    render() {
        return (
            <button onClick={this.handleClick}>Click</button>
        );
    }
    
    handleClick = () => {
        console.log(this);
    }
}

export default App;
```

React 专题 07 —— 事件


刀耕火种时期的前端，HTML描述页面结构，CSS描述样式，JavaScript描述功能。它们彼此是分离的。

然而这种方式却满足不了开发者对代码复用的需求。

近几年各大前端框架做了很多探索，其中组件化就是最璀璨的成果之一。

一个组件就是一个功能模块，所有的前端元素都封装在组件内部，对外只暴露有限的接口。这样开发者拿来就能用，通过接口与组件交互而不必知道组件的内部细节。

而React是前端框架里面组件化思想贯彻的最彻底的。

## class组件和函数组件

在React中，构造一个组件既可以用class类，也可以仅用一个普通函数。

两者有什么区别呢？

class类不仅允许内部状态的存在，还有完整的生命周期钩子。

这让一个组件变的有生命力而且可以管理。

代价就是它的性能稍逊。

还有一点，class类组件必须继承React内置的组件类。因为那些生命周期钩子都是继承自React内置的组件类。

那你说，我不用生命周期钩子，可不可以不继承呢？

不可以，因为你必须要用生命周期钩子。

在一个class类组件中，render方法是必须的，没有了它就不可能返回UI，也就不能称其为一个组件。而render方法就是生命周期钩子之一。

```javascript
import React, { Component } from 'react';

class App extends Component {
    state = { star: 1 };
    
    render() {
        return (
            <div>{this.state.star}</div>
        );
    }
}

export default App;
```

函数组件没有办法实例化，除了一些逻辑判断之外，它的功能只是返回UI。

所以函数组件常常被称为无状态组件。

然而这正是React强大之处，它构建组件可以如此随意，只需要一个普通函数返回一段JSX元素。在React中，有的时候函数和组件的界限会非常模糊。

有一种设计模式把React组件分为容器组件和展示组件，容器组件管理数据、状态和业务逻辑，展示组件仅仅负责接收props展示UI。

所以函数组件的使命肯定是做好展示组件咯。

```javascript
import React from 'react';

function App(props) {
    return (
        <div>{props.star}</div>
    );
}

export default App;
```

那么在React中函数和组件的区别到底在哪？

组件必须返回一段JSX元素，class类组件和函数组件都一样。

## Component和PureComponent

前面说到class类组件有完整的生命周期钩子。这些生命周期钩子是从哪来的呢？毕竟class类组件就是原生的class类写法。

其实React内置了一个`Component`类，生命周期钩子都是从它这里来的，麻烦的地方就是每次都要继承。

#### `PureComponent`类又是干嘛用的？

凭名字猜测，它是一个纯纯的组件类。

怎么个纯法子？

它自动帮开发者做了一些优化工作，使得组件看起来更加纯粹。

而组件性能优化的主要手段就是通过`shouldComponentUpdate`生命周期钩子。

我们来看看它是如何自动优化的。

从下面的例子看，React专门有一个方法来判断组件该不该更新。如果`typeof instance.shouldComponentUpdate === 'function'`，那这就是一个继承了`Component`类的组件，直接执行`shouldComponentUpdate`，返回true则更新，返回false则不更新。

如果`ctor.prototype.isPureReactComponent`，那这就是一个继承了`PureComponent`类的组件，这时React会将`oldProps`和`newProps`做一层浅比较，同时将`oldState`和`newState`做一层浅比较，只要有一个浅比较不相等，则返回true更新，否则返回false不更新。

```javascript
function checkShouldComponentUpdate(
    workInProgress,
    oldProps,
    newProps,
    oldState,
    newState,
    newContext,
) {
    const instance = workInProgress.stateNode;
    const ctor = workInProgress.type;
    if (typeof instance.shouldComponentUpdate === 'function') {
        startPhaseTimer(workInProgress, 'shouldComponentUpdate');
        const shouldUpdate = instance.shouldComponentUpdate(
            newProps,
            newState,
            newContext,
        );
        stopPhaseTimer();
        return shouldUpdate;
    }
    if (ctor.prototype && ctor.prototype.isPureReactComponent) {
        return (
            !shallowEqual(oldProps, newProps) || !shallowEqual(oldState, newState)
        );
    }
    return true;
}
```

`shallowEqual`又干了什么呢？

- 首先用Object.is判断是否相等(React自己写的polyfill)。
- 如果Object.is判断不相等，再作引用类型的比较，比较属性key的长度，比较属性key的一一对应，比较属性value的引用。

总的来说，它只做了一层比较，所以才叫做浅比较。

聪明的你肯定要问了：为什么不递归呢(并发射一个傲娇脸)？

因为递归的深比较非常耗费性能。`PureComponent`类只是帮开发者适度优化性能，它还是要找到成本与收益的平衡点的。

#### `PureComponent`类有其正确打开方式

例如像数组这样的数据结构，在不改变引用的情况下，使用数组的方法操作数组，然后再setState该数组，组件是不会更新的。

你说不对呀，老数组和新数组虽然是同一个引用，但是长度不一样了，浅比较是能识别出来的呀。

我们以上面的例子来看，pop方法会修改老数组，所以此时老数组和新数组是一模一样的，引用一样，长度一样。

React拿着这两份数据做浅比较，肯定返回true。

```javascript
import React, { Component } from 'react';

class App extends Component {
    state = {
        list: [1, 2, 3],
    };
    
    render() {
        const { list } = this.state;
        return (
            <div>
                <button onClick={this.handleDelete}>Delete</button>
                <ul>{list.map(n => <li key={n}>{n}</li>)}</ul>
            </div>
        );
    }

    handleDelete = () => {
        this.state.list.pop();
        this.setState((prevState) => ({ list: prevState.list }));
    }
}

export default App;
```

这就是会误导开发者的地方。

正确的做法是永远不修改原数据，生成新数据时依赖于原数据的浅拷贝，避免新数据和老数据指向同一个引用。

```javascript
import React, { Component } from 'react';

class App extends Component {
    state = {
        list: [1, 2, 3],
    };
    
    render() {
        const { list } = this.state;
        return (
            <div>
                <button onClick={this.handleDelete}>Delete</button>
                <ul>{list.map(n => <li key={n}>{n}</li>)}</ul>
            </div>
        );
    }

    handleDelete = () => {
        this.setState((prevState) => ({ list: [...prevState.list].pop() }));
    }
}

export default App;
```

当然还有一种情况，采用传入时定义的方式给子组件传递props。

结果就是子组件做props的浅比较时永远返回false，因为每次的值都是重新定义的，绝非同一个引用。

那`PureComponent`类就失去它的意义了。

```javascript
import React from 'react';

function App() {
    return (
        <Child method={value => console.log(value)} />
    );
}

export default App;
```

总之，要想使用`PureComponent`类，得时刻盯紧引用数据类型。

在继承了`PureComponent`类的组件里写`shouldComponentUpdate`生命周期钩子会怎么样？

小伙子果然骨骼清奇。

原则上，React并不推荐这种写法，并且在开发环境下会打印一个警告。

你要么偷个懒让React帮你做优化，要么自己做优化，这么干不是赤裸裸的挑衅么！

不过React早就预测到你会这么干的，所以它只能随你的脾气，只要组件里定义了`shouldComponentUpdate`生命周期钩子，`PureComponent`类的自动优化就不再起作用了。

## 组件复用

话说代码复用还真不是因为开发者懒。

假如一个蓝色卡片组件，分别有十个地方要用到。而且这个开发者异常勤奋，把这段代码小心翼翼的复制到这十个地方。看起来大功告成了。但是有一天，产品经理说：“我希望卡片背景换成柠檬色，再删减掉一些信息。”

那么问题来了：该开发者是应该砍死产品经理还是应该考虑代码复用？

React世界中一切都是组件，组件思想的根本诉求又是什么呢？当然是代码复用。一个组件就好像一个集装箱，我不用知道里面装的什么货物，我只用知道它能上我的货轮。

集装箱是商业世界的伟大发明，组件也是前端世界的伟大发明。

React的代码复用都是以组件为单位的。

#### 组件四海为家

最普通的组件复用的方式就是直接使用组件。

一个`<Card />`组件，我可以将它放在任何地方。它对外可以提供一些接口，以保证填充所在上下文要求的内容。开发者可以很方便的一处修改，处处生效。

#### 高阶组件

首先我们回忆一下，什么是高阶函数？

定义非常简单：一个函数，它的参数是函数，或者它的返回值是函数。

基本就是鸡吃鸡或者鸡生鸡的意思。

那么高阶组件就好理解了。它的定义是：一个函数，传入一个组件，并且返回一个组件。

区别就是，高阶函数只要满足一个条件，高阶组件要满足两个条件。

高阶组件既是函数，也是组件，因为在React中一个函数只要返回JSX元素就是组件。但这个组件有点特殊，因为它不是用来堆砌UI的，而是一个组件装饰工厂。

话不多说，我们直接来看一下`react-redux`中的`connect`方法(极度简化的伪代码)。

`connect`方法是用来将redux中的state作为props传给组件的。这就是一个典型的高阶组件，当然它还在外面套了一层函数，为了传值。

不使用`connect`方法的组件是这样导出的：`export default App;`。

使用`connect`方法的组件是这样导出的：`export default connect(mapState, mapDispatch)(App);`。

开发者首先传参执行connect，然后再传组件执行返回的函数，导出的组件就多了一些属性。

可以看出，这种类型的高阶组件主要是为了给目标组件传递一些props。

```javascript
import React, { Component } from 'react';

function connect(mapStateToProps, mapDispatchToProps) {
    return function wrapWithConnect(WrappedComponent) {
        return class Connect extends Component {
            render() {
                return (
                    <WrappedComponent {...mapStateToProps} {...mapDispatchToProps} />
                );
            }
        }
    }
}

export default connect;
```

说高阶组件是一个组件装饰工厂是有道理的，因为我们可以用装饰器的写法来部署高阶组件。

下面是`connect`方法的装饰器写法。

```javascript
import React, { Component } from 'react';

@connect(mapStateToProps, mapDispatchToProps);
class App extends Component {
    render() {
        return (
            <div>app</div>
        );
    }
}

export default App;
```

另一种类型的高阶组件更加巧妙，它使用到了继承的特性。

返回的组件可以获得传入组件的所有属性和方法，如果复用组件需要对传入组件做一些侵入性比较强的改动，那么这种方式非常具有灵活性。

```javascript
import React from 'react';

function HOC(WrappedComponent) {
    return class WithComponent extends WrappedComponent {
        render() {
            return (
                <WrappedComponent />
            );
        }
    }
}

export default HOC;
```

理解高阶组件的精髓是什么呢？我认为是理解复用的到底是什么。

假如我们造一个组件，然后用到不同的地方，那直接用就好了，组件本身就是可复用的。

关键在于组件之外的东西。我们需要重复的给一个组件传入props，或者我们需要重复的给组件增强一些功能。这些都可以理解为组件的装饰，高阶组件其实解决的是组件装饰的复用。

大多数时候，使用高阶组件的场景都有更简单的替代方案。

高阶组件之所以这么流行，是因为React生态系统中很多库都有高阶组件的身影，它们或许是为了提供一个优雅的API，或许是需要处理复杂的场景，或许是...炫技。

如果哪天你复用组件时产生了瓶颈，不妨来看看老朋友高阶组件，它有多强大完全取决于你。

忘了告诉你们，高阶组件简称HOC，高阶组件的第一种类型叫属性代理，第二种类型叫反向继承。不过让这些概念都见鬼去吧，它只会让初学者望而却步。

## render props

高阶组件就是传入一个组件，然后返回一个组件。

那我能不能不通过函数的参数传递组件，比如说通过props传递呢？

这是一个绝好的思路。

它有一个名字叫`render props`。

当然，`render props`也需要一个用来复用的容器。通过给这个容器传递render属性，它可以渲染不同的组件。

属性名是无所谓的，render或者rander都可以，关键它的值得是一个组件，或者说无状态组件。

```javascript
import React, { Component } from 'react';

class WithRender extends Component {
    state = { star: 1 }

    render() {
        return (
            <div>{this.props.render(this.state)}</div>
        );
    }
}
```

`react-router`中的`withRouter`方法就是用的`render props`。

```javascript
const withRouter = (Component) => {
    return (props) => {
        return (
            <Route children={routeComponentProps => <Component {...routeComponentProps} />} />
        );
    }
}
```

React 专题 06 —— 组件


生命周期，顾名思义，就是从生到死的过程。

而生命周期钩子，就是从生到死过程中的关键节点。

普通人的一生有哪些生命周期钩子呢？

- 出生
- 考上大学
- 第一份工作
- 买房
- 结婚
- 生子
- 孩子的生命周期钩子
- 退休
- 临终遗言

每到关键节点，我们总希望有一些沉思时刻，因为这时候做出的决策会改变人生的走向。

React组件也一样，它会给开发者一些沉思时刻，在这里，开发者可以改变组件的走向。

## 异步渲染下的生命周期

React花了两年时间祭出Fiber渲染机制。

简单来说，React将diff的过程叫做Reconciliation。以前这一过程是一气呵成的，Fiber机制把它改成了异步。异步技能将在接下来的版本中逐步解锁。

明明是一段同步代码，怎么就异步了呢？

原理是Fiber把任务切成很小的片，每执行一片就把控制权交还给主线程，待主线程忙完手头的活再来执行剩下的任务。当然如果某一片的执行时间就很长(比如死循环)，那就没主线程什么事了，该崩溃崩溃。

这会给生命周期带来什么影响呢？

影响就是挂载和更新之前的生命周期都变的不可靠了。

为什么这么讲？因为Reconciliation这个过程有可能暂停然后继续执行，所以挂载和更新之前的生命周期钩子就有可能不执行或者多次执行，它的表现是不可预期的。

因此16之后的React生命周期迎来了一波大换血，以下生命周期钩子将被逐渐废弃：

- componentWillMount
- componentWillReceiveProps
- componentWillUpdate

看出特点了么，都是带有`will`的钩子。

目前React为这几个生命周期钩子提供了别名，分别是：

- UNSAFE_componentWillMount
- UNSAFE_componentWillReceiveProps
- UNSAFE_componentWillUpdate

React17将只提供别名，彻底废弃这三个大活宝。取这么个别名意思就是让你用着恶心。

## constructor()

React借用class类的`constructor`充当初始化钩子。

React几乎没做什么手脚，但是因为我们只允许通过特定的途径给组件传递参数，所以`constructor`的参数实际上是被React规定好的。

React规定`constructor`有三个参数，分别是`props`、`context`和`updater`。

- `props`是属性，它是不可变的。
- `context`是全局上下文。
- `updater`是包含一些更新方法的对象，`this.setState`最终调用的是`this.updater.enqueueSetState`方法，`this.forceUpdate`最终调用的是`this.updater.enqueueForceUpdate`方法，所以这些API更多是React内部使用，暴露出来是以备开发者不时之需。

在React中，因为所有class组件都要继承自`Component`类或者`PureComponent`类，因此和原生class写法一样，要在`constructor`里首先调用`super`方法，才能获得`this`。

`constructor`生命周期钩子的最佳实践是在这里初始化`this.state`。

当然，你也可以使用属性初始化器来代替，如下：

```javascript
import React, { Component } from 'react';

class App extends Component {
    state = {
        name: 'biu',
    };
}

export default App;
```

## componentWillMount()

> 💀这是React不再推荐使用的API。

这是组件挂载到DOM之前的生命周期钩子。

很多人会有一个误区：这个钩子是请求数据然后将数据插入元素一同挂载的最佳时机。

其实`componentWillMount`和挂载是同步执行的，意味着执行完这个钩子，立即挂载。而向服务器请求数据是异步执行的。所以无论请求怎么快，都要排在同步任务之后再处理，这是辈分问题。

也就是说，永远不可能在这里将数据插入元素一同挂载。

并不是说不能在这里请求数据，而是达不到你臆想的效果。

它被废弃的原因主要有三点：

- 本来它就没什么用。估计当初是为了成双成对所以才创造了它吧。
- 如果它声明了定时器或者订阅器，在服务端渲染中，`componentWillUnmount`生命周期钩子中的清除代码不会生效。因为如果组件没有挂载成功，`componentWillUnmount`是不会执行的。姚明说的：没有挂载就没有卸载。
- 在异步渲染中，它的表现不稳定。

初始化`this.state`应该在`constructor`生命周期钩子中完成，请求数据应该在`componentDidMount`生命周期钩子中完成，所以它不仅被废弃了，连继任者都没有。

## static getDerivedStateFromProps(props, state)

> 👽这是React v16.3.0发布的API。

首先，这是一个静态方法生命周期钩子。

也就是说，定义的时候得在方法前加一个`static`关键字，或者直接挂载到class类上。

简要区分一下实例方法和静态方法：

- 实例方法，挂载在`this`上或者挂载在`prototype`上，class类不能直接访问该方法，使用`new`关键字实例化之后，实例可以访问该方法。
- 静态方法，直接挂载在class类上，或者使用新的关键字`static`，实例无法直接访问该方法。

问题是，为什么`getDerivedStateFromProps`生命周期钩子要设计成静态方法呢？

这样开发者就访问不到`this`也就是实例了，也就不能在里面调用实例方法或者setsState了。

```javascript
import React, { Component } from 'react';

class App extends Component {
    render() {
        return (
            <div>React</div>
        );
    }

    static getDerivedStateFromProps(props, state) {}
}

export default App;
```

这个生命周期钩子的使命是根据父组件传来的props按需更新自己的state，这种state叫做衍生state。返回的对象就是要增量更新的state。

它被设计成静态方法的目的是保持该方法的纯粹，它就是用来定义衍生state的，除此之外不应该在里面执行任何操作。

这个生命周期钩子也经历了一些波折，原本它是被设计成`初始化`、`父组件更新`和`接收到props`才会触发，现在只要渲染就会触发，也就是`初始化`和`更新阶段`都会触发。

## render()

作为一个组件，最核心的功能就是把元素挂载到DOM上，所以`render`生命周期钩子是一定会用到的。

`render`生命周期钩子怎么接收模板呢？当然是你return给它。

但是不推荐在return之前写过多的逻辑，如果逻辑过多，可以封装成一个函数。

```javascript
render() {
    // 这里可以写一些逻辑
    return (
        <div>
            <input type="text" />
            <button>click</button>
        </div>
    );
}
```

注意，千万不要在`render`生命周期钩子里调用`this.setState`，因为`this.setState`会引发render，这下就没完没了了。主公，有内奸。

## componentDidMount()

这是组件挂载到DOM之后的生命周期钩子。

这可能是除了`render`之外最重要的生命周期钩子，因为这时候组件的各方面都准备就绪，天地任你闯。

这就是社会哥，人狠话不多。

## componentWillReceiveProps(nextProps)

> 💀这是React不再推荐使用的API。

`componentWillReceiveProps`生命周期钩子只有一个参数，更新后的props。

该声明周期函数可能在两种情况下被触发：

- 组件接收到了新的属性。
- 组件没有收到新的属性，但是由于父组件重新渲染导致当前组件也被重新渲染。

初始化时并不会触发该生命周期钩子。

同样，因为Fiber机制的引入，这个生命周期钩子有可能会多次触发。

## shouldComponentUpdate(nextProps, nextState)

这个生命周期钩子是一个开关，判断是否需要更新，主要用来优化性能。

有一个例外，如果开发者调用`this.forceUpdate`强制更新，React组件会无视这个钩子。

`shouldComponentUpdate`生命周期钩子默认返回true。也就是说，默认情况下，只要组件触发了更新，组件就一定会更新。React把判断的控制权给了开发者。

不过周到的React还提供了一个`PureComponent`基类，它与`Component`基类的区别是`PureComponent`自动实现了一个`shouldComponentUpdate`生命周期钩子。

对于组件来说，只有状态发生改变，才需要重新渲染。所以`shouldComponentUpdate`生命周期钩子暴露了两个参数，开发者可以通过比较`this.props`和`nextProps`、`this.state`和`nextState`来判断状态到底有没有发生改变，再相应的返回true或false。

什么情况下状态没改变，却依然触发了更新呢？举个例子：

父组件给子组件传了一个值，当父组件状态变化，即便子组件接收到的值没有变化，子组件也会被迫更新。这显然是非常不合理的，React对此无能为力，只能看开发者的个人造化了。

```javascript
import React, { Component } from 'react';
import Child from './Child';

class App extends Component {
    state = { name: 'React', star: 1 };

    render() {
        const { name, star } = this.state;
        return (
            <div>
                <Child name={name} />
                <div>{star}</div>
                <button onClick={this.handle}>click</button>
            </div>
        );
    }

	handle = () => {
        this.setState(prevState => ({ star: ++prevState.star }));
    }
}

export default App;
```

```javascript
import React, { Component } from 'react';

class Child extends Component {
    render() {
        return <h1>{this.props.name}</h1>;
    }

    shouldComponentUpdate(nextProps, nextState) {
        if (this.props === nextProps) {
            return false;
        } else {
            return true;
        }
    }
}

export default Child;
```

同时要注意引用类型的坑。

下面这种情况，`this.props`和`nextProps`永远不可能相等。

```javascript
import React, { Component } from 'react';
import Child from './Child';

class App extends Component {
    state = { name: 'React', star: 1 };

    render() {
        return (
            <div>
                <Child name={{ friend: 'Vue' }} />
                <div>{this.state.star}</div>
                <button onClick={this.handle}>click</button>
            </div>
        );
    }

	handle = () => {
        this.setState(prevState => ({ star: ++prevState.star }));
    }
}

export default App;
```

```javascript
import React, { Component } from 'react';

class Child extends Component {
    render() {
        return <h1>{this.props.friend}</h1>;
    }

    shouldComponentUpdate(nextProps, nextState) {
        if (this.props === nextProps) {
            return false;
        } else {
            return true;
        }
    }
}

export default Child;
```

解决方法有两个：

- 比较`this.props.xxx`和`nextProps.xxx`。
- 在父组件用一个变量将引用类型缓存起来。

所以`this.state`和`nextState`是只能用第一种方法比较了，因为React每次更新state都会返回一个新对象，而不是修改原对象。

## componentWillUpdate(nextProps, nextState)

> 💀这是React不再推荐使用的API。

`shouldComponentUpdate`生命周期钩子返回true，或者调用`this.forceUpdate`之后，会立即执行该生命周期钩子。

要特别注意，`componentWillUpdate`生命周期钩子每次更新前都会执行，所以在这里调用`this.setState`非常危险，有可能会没完没了。

同样，因为Fiber机制的引入，这个生命周期钩子有可能会多次调用。

## getSnapshotBeforeUpdate(prevProps, prevState)

> 👽这是React v16.3.0发布的API。

顾名思义，保存状态快照用的。

它会在组件即将挂载时调用，注意，是即将挂载。它甚至调用的比`render`还晚，由此可见`render`并没有完成挂载操作，而是进行构建抽象UI的工作。`getSnapshotBeforeUpdate`执行完就会立即调用`componentDidUpdate`生命周期钩子。

它是做什么用的呢？有一些状态，比如网页滚动位置，我不需要它持久化，只需要在组件更新以后能够恢复原来的位置即可。

`getSnapshotBeforeUpdate`生命周期钩子返回的值会被`componentDidUpdate`的第三个参数接收，我们可以利用这个通道保存一些不需要持久化的状态，用完即可舍弃。

很显然，它是用来取代`componentWillUpdate`生命周期钩子的。

意思就是说呀，开发者一般用不到它。

## componentDidUpdate(nextProps, nextState, snapshot)

这是组件更新之后触发的生命周期钩子。

搭配`getSnapshotBeforeUpdate`生命周期钩子使用的时候，第三个参数是`getSnapshotBeforeUpdate`的返回值。

同样的，`componentDidUpdate`生命周期钩子每次更新后都会执行，所以在这里调用`this.setState`也非常危险，有可能会没完没了。

## componentWillUnmount()

这是组件卸载之前的生命周期钩子。

为什么组件快要卸载了还需要沉思时刻呢？

因为开发者要擦屁股吖。

React的最佳实践是，组件中用到的事件监听器、订阅器、定时器都要在这里销毁。

当然我说的事件监听器指的是这种：

```javascript
componentDidMount() {
    document.addEventListener('click', () => {});
}
```

因为下面这种React会自动销毁，不劳烦开发者了。

```javascript
render() {
    return (
        <button onClick={this.handle}>click</button>
    );
}
```

## componentDidCatch(error, info)

> 👽这是React v16.3.0发布的API。

它主要用来捕获错误并进行相应处理，所以它的用法也比较特殊。

定制一个只有`componentDidCatch`生命周期钩子的`ErrorBoundary`组件，它只做一件事：如果捕获到错误，则显示错误提示，如果没有捕获到错误，则显示子组件。

将需要捕获错误的组件作为`ErrorBoundary`的子组件渲染，一旦子组件抛出错误，整个应用依然不会崩溃，而是被`ErrorBoundary`捕获。

```javascript
import React, { Component } from 'react';

class ErrorBoundary extends Component {
    state = { hasError: false };

    render() {
        if (this.state.hasError) {
            return <h1>Something went wrong.</h1>;
        }
        return this.props.children;
    }

    componentDidCatch(error, info) {
        this.setState({ hasError: true });
    }
}

export default ErrorBoundary;
```

```javascript
import React from 'react';
import ErrorBoundary from './ErrorBoundary';
import MyWidget from './MyWidget';

const App = () => {
    return (
        <ErrorBoundary>
            <MyWidget />
        </ErrorBoundary>
    );
}

export default App;
```

## 生命周期

这么多生命周期钩子，实际上总结起来只有三个过程：

- 挂载
- 更新
- 卸载

挂载和卸载只会执行一次，更新会执行多次。

一个完整的React组件生命周期会依次调用如下钩子：

#### old lifecycle

- 挂载
  - constructor
  - componentWillMount
  - render
  - componentDidMount
- 更新
  - componentWillReceiveProps
  - shouldComponentUpdate
  - componentWillUpdate
  - render
  - componentDidUpdate

- 卸载
  - componentWillUnmount

#### new lifecycle

- 挂载

  - constructor
  - getDerivedStateFromProps
  - render
  - componentDidMount

- 更新

  - getDerivedStateFromProps
  - shouldComponentUpdate
  - render
  - getSnapshotBeforeUpdate
  - componentDidUpdate

- 卸载
  - componentWillUnmount

## 组件树生命周期调用栈

应用初次挂载时，我们以`render`和`componentDidMount`为例，React首先会调用根组件的`render`钩子，如果有子组件的话，依次调用子组件的`render`钩子，调用过程其实就是递归的顺序。

等所有组件的`render`钩子都递归执行完毕，这时候执行权在最后一个子组件手里，于是开始触发下一轮生命周期钩子，调用最后一个子组件的`componentDidMount`钩子，然后调用栈依次往上递归。

组件树的生命周期调用栈走的是一个Z字形。

如果根组件没有定义A生命周期钩子而子组件定义了，那调用栈就从这个子组件的A生命周期钩子开始。

另外，只要组件内定义了某个生命周期钩子，即便它没有任何动作，也会执行。

```javascript
app.render();
child.render();
grandson.render();
// divide
grandson.componentDidMount();
child.componentDidMount();
app.componentDidMount();
// divide
app.render();
child.render();
grandson.render();
// divide
grandson.componentDidUpdate();
child.componentDidUpdate();
app.componentDidUpdate();
```
当然，componentWillMount、componentWillReceiveProps和componentWillUpdate生命周期钩子有可能被打断执行，也有可能被多次调用，表现是不稳定的。所以React决定逐步废弃它们。

不过了解整个应用生命周期的正常调用顺序，还是有助于理解React的。

React 专题 05 —— 生命周期


React是用来解决状态同步的，但它却有一个与`this.state`并驾齐驱的概念。

这就是`this.props`。

`this.props`是组件之间沟通的一个接口。

原则上来讲，它只能从父组件流向子组件，但是开发者有各种hack技巧，基本上近亲之间沟通是不成问题的。

## this.props

#### this.props是一个极其简单的接口

你只需要像写HTML标签的属性一样，把它写上去，它就传到了子组件的`this.props`里面。

不过有几个地方需要注意：

- 有两个特殊的属性`ref`和`key`，它们各有用途，并不会传给子组件的`this.props`。
- 如果只给属性不给值，React会默认解析成布尔值`true`。
- 除了字符串，其他值都要用花括号包裹。
- 如果你把属性给了标签而不是子组件，React并不会解析。

```javascript
import React, { Component, createRef } from 'react';
import Child from './Child';

class App extends Component {
    isPopular = false;
    refNode = createRef();
    
    render() {
        return [
            <Child key="react" ref={this.refNode} isPopular />,
            <Child key="vue" url="https://github.com/vuejs/vue" star={96500} />,
            <Child key="angular" owner="google" isPopular={this.isPopular} />,
        ];
    }
}

export default App;
```

#### `this.props`是一个不可变对象

React具有浓重的函数式编程的思想。

提到函数式编程就要提一个概念：纯函数。

纯函数有几个特点：

- 给定相同的输入，总是返回相同的输出。
- 过程没有副作用。
- 不依赖外部状态。

```javascript
function doSomething(a, b) {
    return a + b;
}
```

这是一种编程思想。如果你对这个概念有点模糊，我可以举个例子：

你的杀父仇人十年后突然现身，于是你决定雇佣一个冷面杀手去解决他。

你会找一个什么样的杀手呢？

- 给多少钱办多少事，效果可预期，从不失手。
- 不误伤百姓，不引起动静。
- 没有团伙，单独作案，干净利落，便于封口。

如果你面对杀父仇人有这样的觉悟，那么纯函数便是你的囊中之物了。

为什么要提纯函数？因为`this.props`就是汲取了纯函数的思想。

它最大的特点就是不可变。

跟`this.state`不一样的是，`this.props`来真的。虽然`this.state`也反对开发者直接改变它的属性，但毕竟只是嘴上说说，还是要靠开发者自己的约束。然而`this.props`会直接让你的程序崩溃。

加上React也没有`this.setProps`方法，所以不需要开发者自我约束，`this.props`就是不可变的。

## 沟通基本靠吼

#### 父组件给子组件传值

这个无需赘言，最直观的传值方式。

```javascript
import React from 'react';
import Child from './Child';

const App = () => {
    return (
        <Child star={1000} />
    );
}

export default App;
```

#### 子组件给父组件传值

其实就是利用回调函数的参数传递值。

父组件定义一个方法，将该方法通过props传给子组件，子组件需要给父组件传值时，便传参执行该方法。由于方法定义在父组件里，父组件可以接收到该值。

```javascript
import React, { Component } from 'react';
import Child from './Child';

class App extends Component {
    state = { value: '' };
    
    render() {
        return (
            <Child handleSomething={this.handleSomething} />
        );
    }
    
    handleSomething = (e) => {
        this.setState({ value: e.target.value });
    }
}

export default App;
```

```javascript
import React from 'react';

const Child = (props) => {
    return (
        <input type="text" onChange={props.handleSomething} />
    );
}

export default Child;
```

#### 兄弟组件之间传值

原理和回调函数一样，只不过这里父组件只是一个桥梁。

父组件接收到回调函数的值以后，通过`this.setState`保存该值，并触发另一个子组件重新渲染，重新渲染后另一个子组件便可以获得该值。

```javascript
import React, { Component, Fragment } from 'react';
import ChildA from './ChildA';
import ChildB from './ChildB';

class App extends Component {
    state = { value: '' };
    
    render() {
        return (
            <Fragment>
                <ChildA handleSomething={this.handleSomething} />
                <ChildA value={this.state.value} />
            </Fragment>
        );
    }
    
    handleSomething = (e) => {
        this.setState({ value: e.target.value });
    }
}

export default App;
```

```javascript
import React from 'react';

const ChildA = (props) => {
    return (
        <input type="text" onChange={props.handleSomething} />
    );
}

export default ChildA;
```

```javascript
import React from 'react';

const ChildB = (props) => {
    return (
        <div>{props.value}</div>
    );
}

export default ChildB;
```

#### createContext

> 👽这是React v16.3.0发布的API。

React为开发者提供了一扇传送门，它就是Context对象。

严格来说，Context早就存在于React中了，不过一直以来都不是正式的API。

终于在v16.3.0转正了。

为什么说Context是一扇传送门？因为它可以跨组件传递数据。不是父子之间的小打小闹哦，而是可以跨任意层级。但是有一个限制，数据只能向下传递，原因就是后面要讲到的单向数据流。

开发者通过`createContext`创建一个上下文对象(React特别喜欢create)，然后找一个顶级组件作为`Provider`。接下来就可以在任意下级组件消费它提供的数据了。

- 只要`Provider`的数据改变，就会触发`Consumer`的更新。
- 创建时可以提供一个默认值，另外挂载时可以通过value属性传递数据。但是默认值只有在不提供`Provider`的情况下才起作用。
- 开发者可以创建多个Context。
- `Consumer`的children必须是一个函数。

旧的Context存在一个问题，如果接收组件的`shouldComponentUpdate`生命周期钩子返回false，则它不会接收到Context中的数据，因为它是通过`this.props`一级一级往下传的。

而新的Context采取的是订阅发布模式，所以不存在这个问题。

实际上react-redux库的`Provider`组件内部就是使用了旧的Context API，不过redux做了一些优化。

```javascript
import { createContext } from 'react';

const { Provider, Consumer } = createContext({ lang: 'en' });

export { Provider, Consumer };
```

```javascript
import React, { Component } from 'react';
import { Provider } from './context';
import Todos from './Todos';

const App = () => {
    return (
        <Provider value={{ lang: 'zh' }}>
            <Todos />
        </Provider>
    );
}

export default App;
```

```javascript
import React, { Fragment } from 'react';
import TodoItem from './TodoItem';

const Todos = () => {
    return (
        <Fragment>
            <TodoItem />
            <TodoItem />
            <TodoItem />
        </Fragment>
    );
}

export default Todos;
```

```javascript
import React from 'react';
import { Consumer } from './context';

const TodoItem = () => {
    return (
        <Consumer>
            {({ lang }) => <div>{lang === 'en' ? 'todo' : '要做'}</div>}
        </Consumer>
    );
}

export default TodoItem;
```

## 单向数据流

水往低处流，这是自然规律。

React通过描述状态来控制UI的表达，这就涉及到UI的更新机制。

状态除了内部状态之外，肯定有一些状态是要组件之间共享的，所以，一旦一个组件的状态更新了，可能会牵扯到很多组件的更新，框架的更新机制必将变的异常复杂。

但是回归到水的意象，如果状态的流向是单向的，而且是自上往下流动，这就变的非常符合直觉，而且更新机制可以做到极简：我更新，则我的所有下级也更新。

这就是`this.props`的思想源头。

它虽然叫props，但它也是状态，只不过是共享的状态。

它只能自顶向下流动。

内部不能改变`this.props`。

某个props的源头更新了，则流经的所有组件都要更新，除非开发者手动禁止。

脉络清晰，`this.props`才是赋予了React血液的东西。

关于React摒弃了表单双向数据绑定的问题，它只是想把单向数据流做的更彻底一点。其实表单的状态，归根结底是组件内部的状态，跟单向数据流无关。

什么是双向数据绑定？就是表单输入，与之绑定的变量自动获取到输入的值，变量的值改变，与之绑定的表单的值随即改变，两种流向都自动绑定了。

但其实双向数据绑定不就是value的单向绑定加onChange事件监听么！React也可以通过两步做到。

总结：双向数据绑定不影响单向数据流，React也可以实现双向的同步。

React 专题 04 —— 不可变属性


React使用一个特殊的对象`this.state`来管理组件内部的状态。

然后开发者就可以通过描述状态来控制UI的表达。

如何描述状态呢？

一般我们会在`constructor`生命周期钩子初始化状态。

```javascript
import React, { Component } from 'react';

class App extends Component {
    constructor(props) {
        super(props);
        this.state = { name: '', star: 0 };
    }
}

export default App;
```

也可以直接用属性初始化器的写法，看起来更加简洁。

然后通过`this.setState()`来改变状态。

```javascript
import React, { Component } from 'react';

class App extends Component {
    state = { name: '', star: 0 };
    
    componentDidMount() {
        this.setState({ name: 'react', star: 1 });
    }
}

export default App;
```

## this.state

####  首先，改变状态有特殊的门路

开发者不能直接改变`this.state`的属性，而是要通过`this.setState`方法。

为什么要这样设计？

可能是为了更加语义化吧，开发者清楚自己在更新状态，而不是像Vue那样改变于无形。

不过别急，我为正在阅读的你准备了一个炸弹：

猜猜下面例子最终渲染出来的star是多少？

```javascript
import React, { Component } from 'react';

class App extends Component {
    state = { star: 0 };
    
    componentDidMount() {
        this.state.star = 1000;
        this.setState(prevState => ({ star: prevState.star + 1 }));
    }
    
    // componentDidMount() {
        // this.setState(prevState => ({ star: prevState.star + 1 }));
        // this.state.star = 1000;
    // }
    
    // componentDidMount() {
        // this.state.star = 1000;
        // this.setState({ star: this.state.star + 1 });
    // }
    
    // componentDidMount() {
        // this.setState({ star: this.state.star + 1 });
        // this.state.star = 1000;
    // }
}

export default App;
```

答案是1001。

诶，不是说不能直接改变`this.state`的属性么？

听我讲，首先，`this.state`并不是一个不可变对象，你(非得较劲的话)是可以直接改变它的属性的。但是它不会触发`render`生命周期钩子，也就不会渲染到UI上。

不过，既然你确实改变了它的值，如果之后调用了`this.setState()`的话，它会在你直接改变的值的基础上再做更新。

所以呀少年，要想不懵逼，得靠我们自己的代码规范。

至于注释的部分，只是为了说明顺序问题。

第一部分注释渲染出来的star是1001。因为回调会首先计算star的值，而这时候star的值是1000。

第二部分注释渲染出来的star是1001。这很好理解。

第三部分注释渲染出来的star是1。这也好理解，这个时候star的值还是0。

#### 其次，状态更新会合并处理

大家也看到了，我们可以每次更新部分状态。

新状态并不会覆盖旧状态，而是将已有的属性进行合并操作。如果旧状态没有该属性，则新建。

这类似于`Object.assign`操作。

而且合并是浅合并。

只有第一层的属性才会合并，更深层的属性都会覆盖。

```javascript
import React, { Component } from 'react';

class App extends Component {
    state = { userInfo: { name: '', age: 0 } };
    
    componentDidMount() {
        this.setState({ userInfo: { age: 13 } });
    }
}

export default App;
```

#### 最后，可以有不是状态的状态

如果你需要存储某种状态，但是不希望在状态更新的时候触发`render`生命周期钩子，那么完全可以直接存储到实例的属性上，只要不是`this.state`的属性。使用起来还是很自由的。

## 异步更新

#### 什么叫异步更新？

异步更新说的直白点就是批量更新。

它不是真正的异步，只是React有意识的将状态攒在一起批量更新。

React组件有自己的生命周期，在某两个生命周期节点之间做的所有的状态更新，React会将它们合并，而不是立即触发UI渲染，直到某个节点才会将它们合并的值批量更新。

以下，组件更新之后`this.state.star`的值是1。

```javascript
import React, { Component } from 'react';

class App extends Component {
    state = { star: 0 };
    
    componentDidMount() {
        this.setState({ star: this.state.star + 1 });
        this.setState({ star: this.state.star + 1 });
        this.setState({ star: this.state.star + 1 });
    }
}

export default App;
```

因为这些状态改变的操作都是在组件挂载之后、组件更新之前，所以实际上它们并没有立即生效。

`this.state.star`的值一直是0，尽管状态被多次操作，它得到的值一直是1，因此合并之后`this.state.star`的还是1，并不是我们直觉以为的3。

#### 为什么要异步更新？

因为`this.setState()`会触发`render`生命周期钩子，也就会运行组件的diff算法。如果每次setState都要走这一套流程，不仅浪费性能，而且是完全没有必要的。

所以React选择了在一定阶段内批量更新。

还是以生命周期为界，挂载之前的所有setState批量更新，挂载之后到更新之前的所有setState批量更新，每次更新间隙的所有setState批量更新。

#### 非异步情况

再来看一种情况：

猜猜最终渲染出来的star是多少？

```javascript
import React, { Component } from 'react';

class App extends Component {
    state = { star: 0 };
    timer = null;
    
    componentDidMount() {
        this.timer = setTimeout(() => {
            this.setState({ num: this.state.star + 1 });
            this.setState({ num: this.state.star + 1 });
            this.setState({ num: this.state.star + 1 });
        }, 5000);
    }
    
    componentWillUnmount() {
        clearTimeout(this.timer);
    }
}

export default App;
```

答案是3。

卧槽！

说实话，这里我也没想明白。

我在React仓库的Issues里提过这个情况，这是React主创之一Dan Abramov的回答：

> setState is currently synchronous outside of event handlers. That will likely change in the future.

Dan Abramov所说的`event handlers`应该指的是React合成事件回调和生命周期钩子。

我的理解，因为只有这些方法才能回应事件，所以它们之中的状态更新是批量的。但是它们之中的异步代码里有状态更新操作，React就不会批量更新，而是符合直觉的样子。

我们看下面的例子，正常的重复setState只会触发一次更新，但是http请求回调中的重复setState却会多次触发更新，看来异步的setState不在React掌控之内。

```javascript
import React, { Component } from 'react';

class App extends Component {
    state = { star: 0 };
    
    componentDidMount() {
        fetch('https://api.github.com/users/veedrin/repos')
            .then(res => res.json())
            .then(res => {
                console.log(res);
                this.setState({ star: this.state.star + 1 });
                this.setState({ star: this.state.star + 1 });
                this.setState({ star: this.state.star + 1 });
            });
    }
}

export default App;
```

还有一种情况就是原生的事件回调，比如document上的事件回调，也不是异步的。

总结一下：所谓的异步只是批量更新而已。真正异步回调和原生事件回调中的setState不是批量更新的。

不过，Dan Abramov早就提到过，会在将来的某个版本(可能是17大版本)管理所有的setState，不管是不是在所谓的`event handlers`之内。

React的设计有一种简洁之美，从这种对待开发者反馈的态度可见一斑。

## 回调

既然`this.setState()`的设计不符合直觉，React早就为开发者提供了解决方案。

`this.setState()`的参数既可以是一个对象，也可以是一个回调函数。函数返回的对象就是要更新的状态。

回调函数提供了两个参数，第一个参数就是计算过的state对象，即便这时还没有渲染，得到的依然是符合直觉的计算过的值。同时，贴心的React还为开发者提供了第二个参数，虽然并没有什么卵用。

以下，组件更新之后`this.state.star`的值是3。

有一个小细节：箭头函数如果直接返回一个对象，要包裹一层小括号，以区别块级作用域。

```javascript
import React, { Component } from 'react';

class App extends Component {
    state = { star: 0 };
    
    componentDidMount() {
        this.setState((prevState, prevProps) => ({ star: prevState.star + 1 }));
        this.setState((prevState, prevProps) => ({ star: prevState.star + 1 }));
        this.setState((prevState, prevProps) => ({ star: prevState.star + 1 }));
    }
}

export default App;
```

## chaos

总之呢，React更新状态的设计到处都是坑。

大家对React吐槽最多的点是什么呢？

圈外人吐槽JSX。

圈内人吐槽`this.setState`。

期盼React给开发者一个不令人困惑的状态更新API吧。

React 专题 03 —— 可变状态


话说PHP是世界上最好的语言(笑)。

因为它的入门门槛极低。

```php
<?php
$str = '<ul>';
foreach ($fruits as $fruit) {
    $str += '<li>' . $fruit . '</li>';
}
$str += '</ul>';
?>
```

很多年前，这种字符串拼接开发网页的方式非常流行。

但是这种写法有两个问题：

- 容易造成XSS注入，有极大的安全风险。
- 拼接的写法很繁琐。

于是facebook的工程师开始动歪脑筋了。

## XHP

他们的解决方案也很新颖，就是在代码里直接写标签，而不是将标签视为字符串。

前面说到，字符串拼接很容易造成XSS注入。那么什么是XSS注入呢？

比如恶意用户输入这么一段内容：`<script>code</script>`，就可能被程序识别为一段脚本，他可以在脚本里面干任何事情。

于是人们想到的办法是对所有输入转义，转义的作用就是让所有标签无法被识别为标签，而只是标签写法的字符串。用户的输入就会原原本本的展示在页面上。

但是输入转义也有问题，就是容易把字符串拼接的标签也给转义了。大家应该看过页面上大段大段的标签写法的文本吧。

我们来看看XHP的写法。

```php
<?hh
$post =
    <div class="post">
        <h2>{$post}</h2>
        <p><span>Hey there.</span></p>
        <a href={$like_link}>Like</a>
    </div>;
```

诶，是不是有点眼熟？

XHP把标签与字符串区别开来了，变成脚本语法的一部分。

这正好解决了前面提到的两个问题：

- 标签就是标签，字符串就是字符串，再也别想浑水摸鱼。
- 像写脚本一样写标签，是不是爽多了？

## JSX

其实facebook一直在前端组件化方面做各种尝试，但都不是特别成功。

直到2013年，工程师Jordan Walke提出一个大胆的想法：把XHP的写法迁移到JavaScript中来。即便有XHP的案例在前，大家还是觉得这个想法很疯狂。

不过，facebook极为优秀的工程师文化最终促成了这种尝试。这一尝试不得了，开了天眼。

自此之后就开启了React的开挂之路。

```javascript
const element = <h1>Hello React!</h1>;
```

这不就是facebook一直在苦苦求索的前端组件化方案吗？

刀耕火种时期的前端，入口是HTML，脚本和样式被引入到HTML页面上。这是一种分离化的思想，以语言为最小颗粒。

然而经过大量痛苦的实践，人们发现以内容为最小颗粒才是正解。以组件为单位，页面结构、样式和功能都被集成在组件内部，对开发者来说组件就是一个黑匣子，只能通过暴露出来的接口使用组件。这是一种封装的思想，目的当然是为了复用。

当然，目前React还无法实现真正意义上的CSS封装，不过以当下前端的关注度，CSS被彻底招安也指日可待。

#### 语法

标签的写法和HTML一样，只不过融入到了JavaScript中。

组件，其实就是自定义标签，首字母必须大写，为了与原生标签区别开来。

如果标签或组件没有包含内容，可以采用自闭合标签写法。

```javascript
const element = <App />;
```

JSX会自动忽略`false`、`null`和`undefined`。

标签的`class`属性和`for`属性要用`className`属性和`htmlFor`属性代替。

组件返回多个标签或多个组件必须要用一个标签或组件包裹，也就是说只能有一个顶层元素。

但是，React16以上的版本支持用空标签包裹或者直接返回数组。这样的好处就是不必添加很多无用的标签使页面变得更加臃肿。

```javascript
import React, { Fragment } from 'react';

const App = () => {
    return (
        <Fragment>
            <div>React</div>
            <div>Vue</div>
            <div>Angular</div>
        </Fragment>
    );
}

export default App;
```

```javascript
import React from 'react';

const App = () => {
    return (
        <>
            <div>React</div>
            <div>Vue</div>
            <div>Angular</div>
        </>
    );
}

export default App;
```

```javascript
import React from 'react';

const App = () => {
    return [
        <div key="1">React</div>,
        <div key="2">Vue</div>,
        <div key="3">Angular</div>,
    ];
}

export default App;
```

#### 表达式

标签里肯定要写一些变量，要不然页面就是死的。

怎么写变量呢？用花括号包围。

```javascript
const name = 'React';
const element = <h1>Hello {name}!</h1>;
```

如果我想插入一个对象字面量怎么办？

很简单，再包裹一层花括号。

```javascript
const obj = { name: 'React' };
const element = <h1 style={{ color: '#f66' }}>Hello {name}!</h1>;
```

实际上花括号语法支持所有的表达式。

那么问题来了，什么是表达式？

简单来讲，表达式的主要作用是计算和声明，总是有返回值。与之相对，语句的主要作用是逻辑和动作，没有返回值。

以下表达式JSX都支持。

```javascript
const a = <button onClick={() => console.log('react')}>click</button>;

const b = <button onClick={function (){ console.log('react') }}>click</button>;

const c = <div>{popular ? 'react' : 'vue'}</div>;

const d = <div>{popular && 'react'}</div>;

const e = <div>{renderSomething()}</div>;
```

像赋值语句、判断语句和循环语句JSX都不支持。

那开发者要渲染一个列表怎么办？

for循环语句肯定是不行的，好在我们有map函数。因为从上例我们知道，JSX是支持函数执行表达式的。

forEach函数行不行呢？不行，因为它没有返回值。也就是说，filter、find、reduce等有返回值的遍历函数都是可以的。

```javascript
import React, { Component } from 'react';

const list = ['react', 'vue', 'angular'];

class App extends Component {
    render() {
        return (
            <div>{list.map(value => <div key={value}>{value}</div>)}</div>
        );
    }
}

export default App;
```

#### 编译

不知道你们有没有这样的疑问：

- 为什么返回多个标签或组件必须要用一个标签或组件包裹？
- 为什么在根本没有使用`React`这个变量的情况下还要`import React`？

这里就要讲到JSX的编译。

因为JSX不是正确的JavaScript语法，它要经过编译才能被浏览器识别。

目前JSX的编译工作是由babel来完成的。

我们来看看编译都做了哪些工作。

下面的例子，后者是前者编译后的结果。

```javascript
const app = (
    <div className="form">
        <input type="text" />
        <button>click</button>
    </div>
);
```

```javascript
const app = React.createElement(
    "div",
    { className: "form" },
    React.createElement("input", { type: "text" }),
    React.createElement(
        "button",
        null,
        "click",
    ),
);
```

可以看到，标签最后变成了一个函数执行表达式，第一个参数是标签名，第二个参数是属性集合，之后的参数都是子标签。

看到这里，相信也不用我解释了，前面提出的两个问题恍然大悟。

整个UI实际上是通过层层嵌套的`React.createElement`方法返回的，所以我们要在文件开头`import React`，否则编译后就会发现`createElement`没有定义。

`React.createElement`执行的结果是一个对象，对象的属性描述了标签或组件的性状，对象再嵌套子对象。如果顶层返回多个标签，就无法表达为一个对象了。

由于React16引入了Fiber机制，使得返回多标签成为可能(并不清楚原因)。

同时也回答了为什么标签的`class`属性和`for`属性要用`className`属性和`htmlFor`属性代替。在标签里属性怎么写都无所谓，但是`class`和`for`是JavaScript中的关键字，所以要换一种写法。

React里面传递props有一种写法，如果传递的是一个对象，可以用扩展运算符很方便的传递。

下面的例子，`value`先是被扩展运算符将属性分解，然后又被一个对象包裹。这里只是做了一个浅拷贝，并没有其他的含义。所以最终传递给组件的仍然是一个对象。

所以疑问就来了，通常给组件传递属性都是键值对的形式，直接传递一个对象也可以吗？

其实所有的属性最后都会放到一个对象里面，所以两种写法殊途同归。React只不过给了一种快捷方式。

了解编译的过程，很多写法都很好理解了。

```javascript
const value = { a: 1, b: 2 };
const element = <App a={value.a} b={value.b} />;
```

```javascript
const value = { a: 1, b: 2 };
const element = <App {...value} />;
```

React 专题 02 —— JSX


什么是UI？

如果你指的是布局和色彩，那更偏向于设计师的工作。

在现代web领域，大家已经有一个共识：UI是状态的演进。

那么什么是状态(state)？

现代网页往往意味着大量的人机交互，每一次交互都会产生一些数据，这些数据或者放在内存中，网页关闭即销毁，或者发送给服务器永久保存。但无论怎么样，这些数据都是前端要处理的。

带有时间性的交互数据，就是状态。

当页面初始化完成，变化的只有状态，所以我们才说UI是状态的演进。

现代前端框架的使命就是：开发者管理状态，框架根据状态自动生成UI。

首先我们明确一点，状态和UI是一一对应的。

只要状态发生改变，就需要一套新的UI和它匹配。

这就引出了现代前端框架的核心：如何去监控应用的状态？

## Angular

Angular的哲学是监控状态发生改变的所有出口。

这种方式~~简单~~粗暴。

如果发现商场里有在逃通缉犯，那就调动警力封锁所有的出口，逃犯总不可能在商场里过日子。

而且Angular还惊喜的发现其实出口总共没几个。event回调，http回调，timer回调，promise回调，大概就这些了。

那么如何监控这些出口呢？

狸猫换太子，对这些任务做一层封装，开发者调用的实际上是被Angular动过手脚的方法。刚刚说什么来着？相当暴力。大家应该都听说过大名鼎鼎的`zone.js`吧，它就是Angular所谓脏检查的基础设施。

不过Angular已经日薄西山了。陡峭的学习曲线，臃肿的代码库，一代和二代的完全不兼容，注定它要被开发者抛弃。

## Vue

Vue的哲学是监控变量。

变量实际上是状态的容器，无论状态怎么变，最后都要装到变量这个坛子里。

Vue也觉得调动警力实施封锁实在是太粗暴了，现代社会的命脉是什么？是金融啊喂！

我只要监控逃犯的金融账户，就不怕他不消费。掌握他的行踪，实施定点抓捕就可以了。

那么如何监控变量呢？

JavaScript底层有实现，通过`Object.defineProperty`接口的`getter`和`setter`，可以轻易监控变量的读取和更新。当然ES6开放了更加强大的`Reflect`和`Proxy`接口。

具体操作呢，在初始化阶段，Vue会把挂在UI上的变量都读一遍，触发`getter`，然后`getter`会为每个变量维护一个数组(因为一个变量可能被多次应用于UI)，变量以及对应的回调被绑在一起push进数组里。每次开发者更新变量的值就会触发`setter`，`setter`的作用就是执行回调。当然，回调里就是更新UI的动作。

某种程度上说，Vue脱胎于Angular，它带着Angular的遗志，将来是要和React决战光明顶的。

Vue没有让人失望，现在已经是一枚当红流量小生了。

## React

React的哲学是监控DOM的镜像。

人海茫茫抓捕逃犯成本不是高嘛，我们有监控摄像头啊！无数的摄像头基本可以拼凑出一个公共场所的副本，依靠这个副本，警方可以随心所欲的对比、回放、分析，而不需要顾虑部署警力的成本。

React的思路非常奇特，既然框架负责自动更新UI，那UI就应该成为框架的一部分。

现在UI成了框架的画板，开发者在画板上自由作画，阶段性完工后再由React一次性挂到界面上。

这就带来了一个问题：DOM是好惹的吗？这么不尊重它，每次`innerHTML`了事？

React必须解决这个问题，而它的方案是抽象UI(一般称为Virtual DOM)。

当我们说div是一个元素的时候，我们指的不是那个标签，而是与之关联的一个对象，这个对象描述了div的位置和功能，依据这个对象我们是可以复原出一个DOM节点出来的。

可React觉得这个对象还是太臃肿了，对象里只需要包含必要信息即可，于是React提取必要信息构建了一份DOM的镜像。

什么是必要信息呢？对一个节点而言，它的标签类型、属性、子节点引用就是必要信息，无数节点确立其位置就形成了一个树结构，这个树结构和DOM是一一对应的。

当状态更新的时候，React便获得了两份镜像，通过对比这两份镜像，React就可以给UI打补丁，而不是完全覆盖旧的UI了。

React做的事情特别纯粹，你手里有一幅画，你可以在画上作任意更改，React的使命就是在合适的时机将你的更改生成一幅新的画。

## 为什么是React

如果说Angular手里握有足够的警力，Vue手里握有金融命脉，那么React手里握有的是整个地图，这他妈不是开挂了么！

当然，框架之间不能这样简单的去对比，但是对开发者而言，在React架构下，状态的层次感变得异常清晰。

我们已经同意状态是现代网页的核心，也同意UI是状态的演进，那么清晰的状态层次感和开发者对UI足够的掌控力(幻觉)，会给开发者一种莫名的秩序感，这种秩序感才是React备受开发者喜爱的根本原因吧(不接受异议)。

你看，我在画板上作画哟，真的是我在作画哟。

除此之外，React真正的以组件为核心，HTML和CSS都纳入到组件中来，也是它备受开发者喜爱的原因之一。

除此之外，React把UI抽象出来，理论上可以应用到任何界面，也是它备受开发者喜爱的原因之一。

除此之外，JSX的不伦不类，额...是开发者需要克服的心理障碍。