co源码解读

简介: 背景:     闲来无事,翻了下co的源码来看,源码短小精悍,算上注释,一共240行左右;     决定写一篇博客来记录下学习的心得。     TJ大神的co:https://github.com/tj/co   作用:     co通过将Generator函数拆成一个Promise将码...

背景:

    闲来无事,翻了下co的源码来看,源码短小精悍,算上注释,一共240行左右;

    决定写一篇博客来记录下学习的心得。

    TJ大神的co:https://github.com/tj/co

 

作用:

    co通过将Generator函数拆成一个Promise将码农从callback hell中拯救了出来;

 

    下边放出一段代码,对比下co与普通回调版本的区别:

 1 /**
 2  *  回调版本
 3  */
 4 
 5 let fs = require('fs')
 6 
 7 fs.readFile('./package.json', (err, data) => {
 8   if (err) {
 9     return console.log(err)
10   }
11   console.log(data.toString())
12   fs.readFile('./package.json', (err, data) => {
13     if (err) {
14       return console.log(err)
15     }
16     console.log(data.toString())
17   })
18 })
19 
20 /**
21  *  co版本
22  */
23 
24 let co = require('co')
25 let fs = require('fs')
26 
27 co(function * () {
28   let a = yield fs.readFile.bind(null, './package.json')
29   console.log(a.toString())
30   let b = yield fs.readFile.bind(null, './package.json')
31   console.log(b.toString())
32 }).then(console.log, console.error)

 

从代码上看,貌似co是一个同步执行的过程呢。当然,也只是看起来像而已。

 

正题:

    先来说一下co整个执行的过程:

  • 调用co,传入一个Generator函数,函数会返回一个Promise对象
  • 如果传入参数为Generator函数,会执行该函数来进行Generator的初始化
  • 手动执行一次next() 这时Generator函数就会停在第一次遇到yield关键字的地方
  • 获取到yield后边的值,将其转换为一个Promise函数,然后执行之
  • 重复上边两步,直到函数执行完毕

    co关于yield后边的值也是有一定的要求的,只能是一个 Function|Promise|Generator | Array | Object;

    而 Array和Object中的item也必须是 Function|Promise|Generator。

    并且关于function 普通函数并不一定会得到预期的结果,co需要的是 接收一个回调函数 并执行的函数,类似于这样:

1 function doSomething (callback) {
2   callback(null, 'hello')
3 }
4 co(function * () {
5   let result = yield doSomething
6   console.log(result)  // => hello
7 })

 

    总而言之,co执行的肯定是一个Promise,而co会帮你把其他几种类型的值转换为Promise,co绝大部份的代码都是在处理类型的转换;

    当然,在讲类型转换的那一块之前,还是将co执行Generator的那几个函数说一下子,也就是调用co返回的Promise中的那三个函数(onFulfilled、onRejected、next);

    因next与Generator对象的next方法名相同 这里使用 gen.next 表示 Generator对象的next方法。

 

onFulfilled:

    调用gen.next并将上次执行的结果传入gen.next;

    调用next,将gen.next返回的值传入next。

 

onRejected:

    执行流程与 onFulfilled 一致,只不过是将调用的 gen.next 换为了 gen.throw 用来将错误异常抛出。

 

next:

    函数会判断传入参数的done属性,如果为true( 则表示该Generator已经执行完毕),会调用co返回的Promise对象的resolve方法,结束代码执行;

    如果done为false 则表示还需要继续执行,这里会将 yield后边的值(参数的value属性)转换为Promise,并调用then方法传入 onFulfilled 和 onRejected两个函数。

    co整个的执行流程其实就是这样的-.- 

    剩余代码所完成的事情就是将各种不同的类型转换为可执行的Promise对象。

 

thunkToPromise(Function):

    函数返回一个Promise对象,在Promise内部执行了传入的function;

    并会认为回调的第一个参数为Error(这个貌似是个标准...);

    将其余参数打包到一个数组中返回。

 

arrayToPromise(Array):

    Promise有一个方法叫做all,会返回数组中所有Promise执行后的返回值(如果有其中一项被reject掉,所有的都会被reject);

    方法会返回 Promise.all() 的执行结果

1 Promise.all([
2   Promise.resolve('hello'),
3   Promise.resolve('world')
4 ]).then(data => {
5   console.log(data)  // => ['hello', 'world']
6 })

 

 

objectToPromise(Object):

    函数用来将一个Object对象转换为Promise;

    应该是co源码中行数最多的一个函数了  具体做的事儿呢;

    就是将一个Object的每一个key都转换为Promise,并塞到一个数组中;

    执行Promise.all()将上边的数组塞进去;

    当某一个key所对应的Promise函数执行完毕后,会将执行的结果塞回对应的key中;

    全部执行完毕后,就会返回该Object。

 1 {
 2   a: Promise.resolve('hello'),
 3   b: Promise.resolve('world')
 4 }
 5 
 6 // =>
 7 
 8 {
 9   a: 'hello',
10   b: 'world'
11 }

 

 

其余的几个函数就是判断类型了, isPromise、isGenerator、isGeneratorFunction、isObject。

 

小记:

因我司在用koa来搭建web项目,所以会接触到这些东西,就想写点博客记录一下;

本人文笔简直负分,望各位海涵,如有什么不懂的,欢迎邮件骚扰。

jiashunming@outlook.com 

文章相关代码会在GitHub更新:

https://github.com/Jiasm/blog-resource/tree/master/co 

目录
相关文章
|
1月前
|
存储 前端开发 JavaScript
EaselJS 源码分析系列--第四篇
EaselJS 源码分析系列--第四篇
|
Java Spring 容器
【框架源码】SpringBoot核心源码解读之启动类源码分析
【框架源码】SpringBoot核心源码解读之启动类源码分析
【框架源码】SpringBoot核心源码解读之启动类源码分析
|
缓存 分布式计算 监控
【源码解读】| LiveListenerBus源码解读(上)
【源码解读】| LiveListenerBus源码解读
162 0
【源码解读】| LiveListenerBus源码解读(上)
|
存储 SQL 分布式计算
【源码解读】| LiveListenerBus源码解读(下)
【源码解读】| LiveListenerBus源码解读
149 0
【源码解读】| LiveListenerBus源码解读(下)
|
缓存 算法 Java
【Java技术指南】「并发编程专题」Guava RateLimiter针对于限流器的入门到精通(含实战和原理分析)
【Java技术指南】「并发编程专题」Guava RateLimiter针对于限流器的入门到精通(含实战和原理分析)
145 0
【Java技术指南】「并发编程专题」Guava RateLimiter针对于限流器的入门到精通(含实战和原理分析)
|
存储 分布式计算 监控
【源码解读】|SparkEnv源码解读
【源码解读】|SparkEnv源码解读
129 0
|
存储
HashMap源码解读(下篇)
HashMap源码解读(下篇)
98 0
HashMap源码解读(下篇)
|
存储 Java 索引
HashMap源码解读(中篇)
HashMap源码解读(中篇)
102 0
HashMap源码解读(中篇)
|
存储 Java 对象存储
HashMap源码解读(上篇)
HashMap源码解读(上篇)
114 0
HashMap源码解读(上篇)
|
存储 Java 数据库
Java集合源码分析之开篇
初衷 Java集合是我们使用最频繁的工具,也是面试的热点,但我们对它的理解仅限于使用上,而且大多数情况没有考虑过其使用规范。本系列文章将跟随源码的思路,分析实现的每个细节,以期在使用时避免各种不规范的坑。在这里,我们会惊艳于开发者优秀的设计,也会感激先辈们付出的艰辛努力,更重要的是知其所以然,少犯错误,写出优秀的代码。 许多人对集合类的理解是暴力的,当需要保存对象时就使用ArrayList,当需要保存键值对时就使用HashMap,当需要不可重复时就使用HashSet,等等。而且使用方式也比较单一:
195 0