异步处理方案系列- 1.callback

时间 2019-11-16

标签异步处理方案系列 1.callback callback 繁體版

原文原文链接

本篇博客还没有上传 github
github 首页(star+watch，一手动态直达)： https://github.com/HCThink/h-blog
掘金 link , 掘金专栏
segmentfault 主页

原创禁止私自转载javascript

异步处理方案系列- 1.callback

引言

异步/异步操做，已是前端领域一个老生常谈的话题.也是作前端开发中常常面临的一个问题.前端

然而异步的问题每每比较复杂且难于处理, 特别是异步问题还常常不是单独出现,每每存在比较多样的组合关系.java

在实际处理中就显得更加复杂而难于处理. 特别是在 io 操做频繁，或者 node server 中，常常遇到很是复杂的组合型异步。node

举个业务开发中常见的例子:git

eg: 省市县三级级联问题

这个问题很是常见, 假设数据量较大, 咱们大多数状况下不会一次加载全部的数据, 而后作前端级联的方案.es6

而是采起三个数据接口,在下拉改变的时候去动态请求的方式.这就造成一种很常见的多个异步串行的模型.github

怎么处理这样的问题, 怎么较好的维护多个异步之间的关系, 怎么让代码正常执行的同时,在逻辑和结构上更可读呢?ajax

我将会梳理shell

callback
cps
thunk
defer / promise(非 es6)
promise(ES6)
generator -> co.
async / await

这几种处理方式. 加上两种模式编程

事件监听
订阅发布模型

列出一个系列的博客去讨论这个问题.
看咱们在不一样阶段, 使用不一样技术,如何处理相同的问题. 在不一样方案之间横向对比, 去深刻了解
技术变迁以及背后的处理思路和逻辑的变化.

callback

什么是回调呢? 这么问彷佛有点多余, 每一个写过 javascript 的开发者, 或多或少都会接触到回调. 回调的使用成本很低,
实现回调函数就像传递通常的参数变量同样简单.因为函数式编程极好的支持,以致于这项技术使用基本没有障碍.咱们随手就能写出一个回调

Ajax.get('http://xxxx', {}, (resp) => {
    // .....
})

可是呢,要真给回调下一个定义, 也还真很差回答.

咱们不妨从一些侧面去看看回调

回调是一种处理特定问题的模式, 伴随着函数式编程而生. 函数式编程中很重要的技术之一就是回调函数
当一个函数做为主调函数的参数时, 它每每会在特定的时间和场景(上下文)中执行.
执行过程当中,回调函数选择性接收函数内部的数据, 或者状态(内存), 通过处理选择性返回,或者改变状态（hock）.

callback 业务模型

说这么多, 咱们不如从代码的角度去解决一个串行的异步模型.

为了说明问题, 咱们将问题简化成 A B C 三个异步(多是 io, 网络请求, 或者其余.为了方面描述, 咱们采用 settimeout 来模拟), 这三个异步耗时不肯定, 可是必须按照 A B C 的顺序处理他们的返回结果.

处理这个问题, 咱们基本上有两种思路:

控制异步发出的顺序, 在 a 返回以后再发 b 请求, 这样将问题串行化(省市县模型中常常须要省的返回值去请求省所对应的市).
同时发出异步请求,控制处理的顺序.

方案一: 串行化请求

// 模拟 ajax 函数
function ajax(url) {
    return function (cb) {
        setTimeout(function() {
            cb({
                url
            });
        }, Math.random() * 3000);
    }
}

// 初始化出三个请求
const A = ajax('/ofo/a');
const B = ajax('/ofo/b');
const C = ajax('/ofo/c');

// 控制请求顺序
log('ajax A send...');
A(function (a) {
    log('ajax A receive...');

    log('ajax B send...');
    B(function (b) {
        log('ajax B receive...');

        log('ajax C send...');
        C(function (C) {
            log('ajax C receive...');
        });
    })
})

代码很简单, 大可能是方案也是这么走的, 由于 A 的返回值能够做为 B 的参数.
可是相应的这个模式的总时间一定大于三个请求的时间之和.输出以下:

ajax A send...
ajax A receive...
ajax B send...
ajax B receive...
ajax C send...
ajax C receive...

方案二: 自由请求,串行化处理

是相对不那么通用的方案, 可是处理没有直接数据依赖的串行请求很是合适.

// 发送容器
const sender = [];
// 稍做改造
function ajax(url, time) {
    return function(cb) {
        // 记录发送顺序, 必须有序
        sender.push(url);
        setTimeout(function() {
            const data = {
                from: url,
                reso: 'ok'
            };

            // 将 data, 回调传递给一个处理函数
            dealReceive({url, cb, data});
        }, time);
    }
}


// 按照顺序处理返回结果

// 返回结果容器
const receiver = {};
function dealReceive({url, cb, data}) {
    // 记录返回结果.能够无序
    receiver[url] = {cb, data};
    for (var i = 0; i < sender.length; i++) {
        let operate = receiver[sender[i]];
        if(typeof operate === 'object') {

            operate.cb.call(null, operate.data);
        } else {
            return;
        }
    }
}

// 手动模拟出请求时间, A 最耗时.b 最快, 更好说明问题
const A = ajax('/ofo/a', 4000);
const B = ajax('/ofo/b', 600);
const C = ajax('/ofo/c', 2000);


// 注意咱们的调用方式 是没有任何控制的
// A,B,C 依次发出. 还能够按照这个顺序处理 A,B,C 的返回值
A(function (a) {
    log(a);
});

B(function (b) {
    log(b);
});

C(function (c) {
    log(c);
});

输出:

{"from":"/ofo/a","reso":"ok"}
{"from":"/ofo/b","reso":"ok"}
{"from":"/ofo/c","reso":"ok"}

这种方案总耗时基本上是耗时最长的 ajax 的耗时。

值得注意的是, A,B,C 的调用上没有作任何控制. A 最耗时, 可是要最最早处理 A 的返回数据.
实现这一点的关键就在于咱们 dealReceive 有个轮询, 这个轮询不是定时触发的,而是每当请求回来时, 触发轮询. 整个过程轮询 3 次.

基本上 callback 处理组合异步模型的思路说完了.串行是容易处理的一种模型, 若是出现 c 依赖 a,b 都正确返回的模型时, 基本上咱们暴力一点就是转化为串行关系. 尽管 a, b 没有关系.
或者呢咱们就在 a, b 的回调里作标志位. 和 dealReceive 相似.

单个异步不须要有太多处理, callback 的一些细节也不作讨论. 主要讨论是回调在实际场景中的处理问题方案

回调两面性

咱们仍是落入俗套的分析一下回调的优缺点.其实主要是缺点.

优势: 使用成本低, 处理简单问题很是方便.可以拿到主调函数内部的环境.等等.
大多数人认为的缺点:

回调很 low: 多是由于, 实现回调函数就像传递通常的参数变量同样简单.因为函数式编程极好的支持,以致于这项技术使用基本没有障碍.也没有比较严格的模式要求.你们习觉得常了.
回调地狱(代码横向发展): 其实这并非回调的错. 当咱们遇到回调无底洞的时候，也无需惊慌,其实这根本不是什么问题, 由于一样有协程和 monad 无底洞。由于若是你把任何一个抽象使用地足够频繁的话，都一样会创造一个无底洞。

使用回调上的建议: 没有使用障碍致使回调的滥用, 大部分问题都用了简单的回调堆叠来解决. 实际上咱们有不少基于回调的模式能够避免这些问题.好比: cps, cps 进一步转化为 thunk.等等.

这样看来, 回调没有缺点, 是这样么? 不是的. 回调有很是致命的机制上的缺点, 这个问题可能在 node 中爆发，除非自身改变，或者被吃掉。

所谓的机制就是：你可能在用回调处理复杂问题的时候,对本身能力产生怀疑,这些异步之间的关系是那么难以梳理清晰,而又难以写出容易维护的代码.

其实这都不是你的错.

使用回调处理异步每每意味着,你舍弃了返回值,而使用回调接收异步操做结果. 而这正是用回调风格来编程会很困难的根本缘由: 回调风格不返回任何值，因此难以组合[函数式编程中函数有良好的输入和输出是函数能够组合的根本]。
一个没有返回值的函数执行的效果实际上是利用它的反作用
一个没有返回值和利用反作用的函数其实就是一个黑洞。
因此，使用回调风格来编程没法避免会是指令式的，它其实是经过把一系列严重依赖于反作用的操做安排好执行顺序，而不是经过函数的调用来把输入输出值对应好。若是你是经过回调组织程序执行流程, 而不是靠理顺值的关系来解决问题的, 是很难编写出正确的并行程序
这种问题也间接的致使了回调难于调试,定位问题和维护.

最终的结果就是: 你崩溃了

注：系列博客陆续推出，稍安勿躁。