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

写在前面

最近在总结本身在业务开发中遇到的问题，通过思考，发现了一个可能值得总结一下的点：使用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和回调函数在思想上就是不同的。本次总结，某种程度上加深了本身对于语言的理解，符合预期。