管理回调的传统方式
很多人接触到callback hell，就立刻想到promise，generator，想到ES7的async/await，这些话题上的帖子论坛里不少了。
但实际上，在大部分的JS编程场景里管理回调并没有那么吓人，也不是非得一上来就Promise，generator，非得可着劲地用async/await。
比如很常见的回掉代码结构
jQuery('.myclass').on('event', function () {
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
});
回调太长可以“提取”，提取以后的回调，给他一个有意义的名字，代码立刻好读不少
jQuery('.myclass').on('event', meaningfulName);
function meaningfulName() {
...
...
...
...
}
如果要用到很多这样的回调，就把他们“封装”成模块
var mymoduleHandler = (function() {
return {
meaningfulName1: handler1,
meaningfulName2: handler2
};
function handler1() {}
function handler2() {}
}());
这样，消费这些回调的代码就可以缩短，获得最佳可读性
jQuery('.element').on('event', mymoduleHandler.meaningfulName1);
jQuery('.element').on('event', mymoduleHandler.meaningfulName2);
如果要控制回调的执行上下文
jQuery('.element').on('event', mymoduleHandler.meaningfulName3.bind(this));
很多时候，用好“提取”和“封装”其实就能很好地管理好回调了。
12 回复
用pronise并不一定是为了解决callback hell，我是为了更好的捕捉error，一个方法一个自定义error，多层嵌套看起来，每一次都要先判断，很恶心。自定义的error无法满足大项目的需求，所以改用了promise。当然，一开始写js代码还是应该从callback写起
@mosaic101 promise做错误处理更好写一点，但promise有解决callback hell的一些场景下的问题，主要是它方便级联，但仍然不直接解决级联内的callback函数本身的可读可维护问题，一定的提取和封装还是需要的。
