SAP UI5 函数节流和异步完成令牌的应用

版权声明：本文为博主汪子熙原创文章，未经博主允许不得转载。 https://cloud.tencent.com/developer/article/1439834

来自我的同事，SAP成都研究院的架构师Li Ben。

在SAP CRM Fiori App的早期开发过程中，关于live search功能上有一个问题，就是有时候发现live search返回的suggestion item并不完全匹配我们输入的search string, 比如正常情况输入abcde，应该匹配4个结果:

但是有时候输入abcde，会匹配更多的结果，发现里面有些item并不匹配abcde，他们只能匹配abcd:

问题分析

用户输入到abcd和abcde的时候，都向后台发出了请求查询匹配的结果，最后将结果显示到suggestion item中。

App请求的发送有先后顺序(先发abcd，再发abcde)，但是响应处理是通过异步回调，这里不能保证处理返回结果的先后顺序跟请求发送的顺序一致，在用户输入较快，或者后台处理需要一定时间的情况下，有可能第二个请求(abcde)先于第一个请求(abcd)返回。造成的结果是用户最后的输入停留在abcde，而最后的返回结果是匹配的abcd(如上图)。

改进方案

方法1 - Throttle: 函数节流

Throttle又叫函数节流，目标是防止短时间内对一些昂贵的函数做出重复调用。

实现思想是在第一次调用函数的时候做一个定时器，同时设定一个threshold时间(函数的真正逻辑在定时器的threshold时间之后才被定时器执行)，在该threshold之内，如果该函数没有被再次调用，就让定时器执行该函数的逻辑代码；如果threshold之内该函数被再次调用，取消上一次设定的定时器，重新生成一个新的定时器，让真正的逻辑重新被推迟到threshold时间之后执行。例子:

代码看上去还是很直观的。

Throttle - 函数节流的更多介绍：

http://wiki.jikexueyuan.com/project/brief-talk-js/function-throttling.html

方法2：Asynchronous Completion Token(ACT):

ACT最早是用来解决通信系统的多路信号的问题，就是不同的请求发出之后，接受响应的一端需要知道每个响应对应的原始请求是什么。我们live search的问题类似，我们需要知道匹配用户最后输入字符串的那个响应，本质上也是ACT问题的一种。

ACT实现思路简单讲，就是给每个请求和对应的响应分配一个唯一的token，响应返回的时候校验token，具体实现结合应用场景可能有所不同。

我在My Lead上为了验证ACT简单实现了一下：

(1) 定义两个变量缓存响应和用户的最终输入：

(2) 在change事件触发的方法里，让sLastInput保持跟用户的输入一致。

(3) 如果缓存的响应里面已经有了匹配的结果，不需要发出请求，直接从缓存取，这里我将用户最终输入的字符串作为validate token。

(4) 如果缓存里面没有匹配的结果才发出请求，在响应返回的callback里面，缓存结果并校验token:

ACT Pattern的更多介绍: http://www.cs.wustl.edu/~schmidt/PDF/ACT.pdf

这本书里也讲了ACT：

http://software-pattern.org/Book/29

比较一下Throttle和Async Completion Token:

​