回調地獄 (着重於回調地獄的理解,解決辦法網上有很多示例)
這個問題一直圍繞着我,但是自己也沒有去深究 一直的理解就是可以使用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就像是他的中文意思一樣(承諾);它不論是成功或者失敗他都會對你做出回應;而回調可能無法對不可預知的錯誤做出反應,即使可以也肯定需要大量的邏輯判斷最后造成代碼臃腫難以維護結果還是陷入了上文中回調地獄的處境
- 由於現在技術水平不夠,文章就寫到這,以后再來補