管理回调的传统方式
发布于 2 年前 作者 flamingtop 2189 次浏览 来自 分享

很多人接触到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 回复

在多多的了解了解吧

  • Node.js里有EventEmit机制
  • cnode源码里用的是朴大写的EventProxy

不是不能实现,只是不够好而已

用pronise并不一定是为了解决callback hell,我是为了更好的捕捉error,一个方法一个自定义error,多层嵌套看起来,每一次都要先判断,很恶心。自定义的error无法满足大项目的需求,所以改用了promise。当然,一开始写js代码还是应该从callback写起

@mosaic101 首先理解积木是怎么回事儿,哈哈

@i5ting 狼叔(๑•̀ㅁ•́ฅ✧早 From Noder

@i5ting EventEmitter 和 EventProxy 是在程序设计的时候解耦用的更多,本身不是用来规避回调的,至少主要目的不是。

@mosaic101 promise做错误处理更好写一点,但promise有解决callback hell的一些场景下的问题,主要是它方便级联,但仍然不直接解决级联内的callback函数本身的可读可维护问题,一定的提取和封装还是需要的。

我并不是要一概否定高级技巧,而是要强调基本程序设计方法的实用性。

不回调,不node,什么async,promise,co以及其他,恕我直言,都是[哔]。

赞同,并不是必须使用的,自己注意点一般不会写金字塔,

看看隔壁lisp是怎么解决金字塔问题的:不缩进

哈哈不缩进

回到顶部