使用Pull模型来实现前端的业务逻辑

945

本文首发于公众号:符合预期的CoyPan

写在前面

最近在总结自己在业务开发中遇到的问题,经过思考,发现了一个可能值得总结一下的点:使用Pull模型来实现业务逻辑

背景

先不管什么是Pull模型,我们先来看下面的场景:

有一个异步操作A,A完成后,需要根据A返回的结果,再进行下一步的业务逻辑。

一种很常见的实现方式是:

A(res => {
  if(res === true) {
    // 业务逻辑M
  } else {
    // 业务逻辑N
  }
});

这种实现方式没有什么大问题。但是考虑这样一个问题:

经过一段时间的迭代,业务逻辑M和业务逻辑N越来越复杂。这个时候,产品经理突然要加一个前置条件:异步操作A完成后,如果返回值是true,那么需要先进行一个异步操作B,如果B返回的同样是true,再进行业务逻辑M。当这种情况越来越多时,这个时候,代码维护起来就比较麻烦了。

A(resA => {
  if(resA === true) {
    B(resB => {
      if(resB === true) {
        // 业务逻辑M
      }
    })
  } else {
    // 业务逻辑N
  }
});

我之前就遇到了这个问题。

####怎么解决

要解决这个问题,其实很简单。使用promise 和 await。

const resA = await PromiseA();
if(resA === false) {
  // 业务逻辑N
  return ;
}
const resB = await PromiseB();
if(resB === true) {
  // 业务逻辑M
}

改造后的代码,我们就可以很方便的添加前置逻辑、和分支条件判断了。

Pull模型

之所以await可以解决上述问题,是因为:在我看来,await其实可以看做是一个Pull模型。所谓Pull模型,其实是来自消息中间件的一个概念。简单来说,Pull模型就是:我需要什么数据的时候,我再去拿。与之对应的,是Push模型:数据产生了,给你拿去用吧。

结合上面的代码来看,我们来看看Push模型和Pull模型的区别。

Push模型:

const asyncFn = function() {};
const callback = function(res) {
  if(res === true) {
    // ....
  }
};
asyncFn(callback);

上面的代码,异步函数执行完成后,回调函数会立即执行。如果我们想判断异步函数执行的结果后,再去做逻辑,就必须再callback里面写代码。异步函数直接把数据Push给了回调函数,回调函数会立即执行。

Pull模型:

const callback = function() {};
const asyncFn = async function() {};
const asyncRes = await asyncFn();
if(asyncRes === true) {
		callback();
}

上面的代码,从异步函数中Pull了数据后,先进行判断,然后再进入回调函数里面的逻辑。

在我平时的业务开发中,会涉及到许多的异步操作,每一个异步操作都涉及到时序性问题和条件分支问题。使用Pull模型,可以很好的处理异步操作之间的时序问题,并且把代码中的许多if else外置,每一个函数专心实现一个业务逻辑,方便维护,且不易出错。Pull模型可以增强我们对于异步操作的控制能力。

写在后面

业务中使用await来书写代码,可以解决许多问题,其根本原因是await和回调函数在思想上就是不一样的。本次总结,某种程度上加深了自己对于语言的理解,符合预期。