react中的回调地狱详细解析

标签：function 地狱 示例 代码 理解 调用 回调

回调地狱 (着重于回调地狱的理解,解决办法网上有很多示例)
这个问题一直围绕着我,但是自己也没有去深究 一直的理解就是可以使用promise解决,代码布局比较乱,今天为了加深理解就写一下笔记

1.解释
代码示例
var sayhello = function (name, callback) {
setTimeout(function () {
console.log(name);
callback();
}, 1000);
}
sayhello(“first”, function () {
sayhello(“second”, function () {
sayhello(“third”, function () {
console.log(“end”);
});
});
});
代码耦合，一旦修改，原地爆炸。
无法使用try catch，就无法排错，也是原地爆炸
并不是说网上的示例不好,但是我真的还是没有理解地狱回调

2.看了<<你不知道的JavaScript>>这本书才对地狱回调有了深的理解
解释: 文中此书代表着<<你不知道的JavaScript>>这本书

先说一下上面的示例;我自认为这就是嵌套回调(如果有其他观点,大家可以一起讨论),依据来自于此书中的第二卷第二部分的2.2.2章节;书中是这样说的
1.这种代码常常被称为回调地狱（callback hell），有时也被称为毁灭金字塔（pyramid of 回调 ｜ 165doom，得名于嵌套缩进产生的横向三角形状）。
2.但实际上回调地狱与嵌套和缩进几乎没有什么关系。它引起的问题要比这些严重得多,但是它和回调地狱一样脆弱
3.它并没有考虑可能导致步骤执行顺序偏离的异常情况。比如，如果步骤 2 失败，就永远不会到达步骤 3，不管是重试步骤 2，还是跳转到其他错误处理流程，等等。
4.总结: 嵌套和缩进基本上只是转移注意力,造成了逻辑上的混乱(这句我自己稍微修改了下)
简单的小例子说说地狱回调的可怕
如果你出外办事的时候发现把购物清单落在了家里，那么这一天并不会因为你没有预知到这一点就成为世界末日了。你的大脑很容易就能针对这个小意外做出计划：回家拿清单，然后立刻返回商店就是了。 手工硬编码（即使包含了硬编码的出错处理）回调的脆弱本性可就远没有这么优雅了,因为代码不会像大脑一样可以灵活做出反应。一旦你指定（也就是预先计划）了所有的可能事件和路径，代码就会变得非常复杂，以至于无法维护和更新;这才是回调地狱的可怕

假如你是一名开发人员，为某个销售昂贵电视的网站建立商务结账系统。你已经做好了结账系统的各个界面。在最后一页，当用户点击“确定”就可以购买电视时，你需要调用（假设由某个分析追踪公司提供的）第三方函数以便跟踪这个交易。你注意到，可能是为了提高能，他们提供了一个看似用于异步追踪的工具，这意味着你需要传入一个回调函数。在传入的这个 continuation 中，你需要提供向客户收费和展示感谢页面的最终代码。六个月过去了，没有任何问题。你几乎已经忘了自己写过这么一段代码。某个上班之前的早晨，你像往常一样在咖啡馆里享用一杯拿铁。突然，你的老板惊慌失措地打电话过来，让你放下咖啡赶紧到办公室。到了办公室，你得知你们的一位高级客户购买了一台电视，信用卡却被刷了五次，他很生气.通过分析日志，你得出一个结论：唯一的解释就是那个分析工具出于某种原因把你的回调调用了五次而不是一次。他们的文档中完全没有提到这种情况。然后，你开始沿着这个兔子洞深挖下去，考虑着他们调用你的回调时所有可能的出错情况。这里粗略列出了你能想到的分析工具可能出错的情况：
• 调用回调过早（在追踪之前）；
• 调用回调过晚（或没有调用）；
• 调用回调的次数太少或太多（就像你遇到过的问题！）；
• 没有把所需的环境 / 参数成功传给你的回调函数；
• 吞掉可能出现的错误或异常；
这感觉就像是一个麻烦列表，实际上它就是。你可能已经开始慢慢意识到，对于被传给你无法信任的工具的每个回调，你都将不得不创建大量的混乱逻辑。现在你应该更加明白回调地狱是多像地狱了吧。

关于promise
promise就像是他的中文意思一样(承诺);它不论是成功或者失败他都会对你做出回应;而回调可能无法对不可预知的错误做出反应,即使可以也肯定需要大量的逻辑判断最后造成代码臃肿难以维护结果还是陷入了上文中回调地狱的处境