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意义,什么情况下会多次调用?