trunkify和co

thunkify

thunkify原来也是tj大神写的，牛逼。

代码

var fs = require('fs')
var assert = require('assert')

function thunkify (fn) {
  assert('function' === typeof fn, 'function required')
  // 引入断言库判断是不是函数
  // 返回一个包含thunk函数的匿名函数
  return function () {
    var args = new Array(arguments.length)
    // 创建一个数组空间
    var ctx = this
    // 获取上下文环境用于后面绑定上下文

    for (var i = 0; i < args.length; ++i) {
      args[i] = arguments[i]
    }
    // 迭代传参，因为有内存泄漏bug
    // 返回真正的thunk函数
    return function (done) {
      // done相当于是执行后的callback
      var called
      // 声明一个called保证只执行一次这个回调函数
      // 将回调函数放入参数数组中，传到真正的fn中。比如fs.readFile(path, callback)
      // 这里加called的目的是为了防止多次调用done，但是什么情况下会多次调用done呢？
      args.push(function () {
        if (called) return
        called = true
        done.apply(null, arguments)
      })
      // 用try catch 在执行失败也走一次callback 传入err信息
      try {
        fn.apply(ctx, args)
      } catch (err) {
        done(err)
      }
    }
  }
}
var readFile = thunkify(fs.readFile)

var gen = function* () {
  var r1 = yield readFile('./1.txt')
  console.log(r1.toString()) // abc
  var r2 = yield readFile('./2.txt')
  console.log(r2.toString())// def
}

function run (fn) {
  var gen = fn()
  function next(err, data) {
    var result = gen.next(data)
    if (result.done) return
    result.value(next)
  }
  next()
}
run(gen)

前言

thunkify的代码分析已经在上面了，先说一下经过thunkify函数调用后的变化：将原来的方法调用方式改变了，如下

const fs = require('fs')
// 原来
fs.readFile(path, callback)
// 现在
const readFile = thunkify(fs.readFile)
readFile(path)(callback)

这种写法看着很奇怪。等会我们会用到它。

代码执行流程

现在我们讲一下上面函数执行的整体流程。

1.首先我们定义了一个Generator函数gen。

2.执行run方法。将gen传进了run函数中，进入该函数后调用gen，gen不会执行内部逻辑，会返回一个具有next方法的遍历器对象。

3.执行gen.next方法。第一次执行遍历器对象的next方法，这时就开始执行Generator函数，直到遇到第一个yield为止(会执行yield后面跟的语句)。

4.这时gen.next就会返回result，值是一个拥有done和value属性的对象，此时done为false，value值为thunkify中最里层return的函数。

5.这时继续执行result.value(也就是thunkify中最里层return的函数)，注意，此时将next方法传了进去。等会会在函数内部调用next，其实是个递归。

6.看下图，会将回调函数和之前传入的参数一起传入真正的fn中执行。

    return function (done) {
      // done相当于是执行后的callback
      var called
      // 声明一个called保证只执行一次这个回调函数
      // 将回调函数放入参数数组中，传到真正的fn中。比如fs.readFile(path, callback)
      // 这里加called的目的是为了防止多次调用done，但是什么情况下会多次调用done呢？
      args.push(function () {
        if (called) return
        called = true
        done.apply(null, arguments)
      })
      // 用try catch 在执行失败也走一次callback 传入err信息
      try {
        fn.apply(ctx, args)
      } catch (err) {
        done(err)
      }
    }

在这里就是下图

fs.readFile('./1.txt', () ={
    if (called) return
        called = true
        done.apply(null, arguments)
})

7.这时候等读完文件，就会调用done方法，done就是刚刚咱们传进来的next方法。将拿到的数据传入到gen.next方法中，执行该方法。作为第一次yield产出的数据，这时候控制权交回给Generator函数，继续往下执行，打印出了1.txt的文件内容。

8.然后继续执行函数内的内容，碰到了第二个yield函数，执行yield后面的内容。拿到的返回值还是一个函数。这时候控制权又移交了出去。代码执行到了赋值给result的地方。

9.这时候就和刚才的逻辑一样了。

总结

yield和await
- yield并不和await一样，等待后面的promise转为fulfilled状态。之前一直误解了。yield后跟任何数据结构的值都可以，只是一个暂停的标志。需要通过执行next方法继续执行下一步。
thunkify
- thunkify做的就是将回调函数和其他参数分离开，这样造成的结果就是，在Generator函数中，更像是声明了一个异步操作，其实执行放在返回的函数中，这样就可以在回调中执行next方法，起到Generator函数自执行的目的。

co

co的本质其实和thunkify没有区别，thunkify是在回调函数中调用next，自执行。co则是then。下面给一个简略版的实现


// 调用代码
co2(function* () {
  var result = yield Promise.resolve(true)
  var result2 = yield new Promise((resolve) => {
    setTimeout(() => {
      resolve(22222)
    }, 3000)
  })
  return {result, result2}
}).then(function (value) {
  console.log(11111, value)
}, function (err) {
  console.error(err.stack)
})

// 模拟co实现，这里非常缺少错误处理机制
function co2 (gen) {
  return new Promise((resolve, reject) => {
    const iterator = gen()
    function run (...args) {
      const result = iterator.next(...args)
      const {value, done} = result
      if (done) {
        resolve(value)
      } else {
        value.then((...args) => {
          run(...args)
        })
      }
    }
    run()
  })
}

遗留问题

错误处理机制
arguments内存泄漏
thunkify中的called意义，什么情况下会多次调用？