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

ID: 符合预期的CoyPan
CoyPan，BAT某厂符合预期的FE，正努力成为一名出色的工程师

写在前面

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

ID: 符合预期的CoyPan
CoyPan，BAT某厂符合预期的FE，正努力成为一名出色的工程师