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

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

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

clipboard1

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

clipboard2

问题分析

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

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

改进方案

方法1 - Throttle: 函数节流

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

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

clipboard3

代码看上去还是很直观的。
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) 定义两个变量缓存响应和用户的最终输入:

clipboard4

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

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

clipboard5

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

clipboard6

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

这本书里也讲了ACT:

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

比较一下Throttle和Async Completion Token:

clipboard7

要获取更多Jerry的原创文章,请关注公众号"汪子熙":

展开阅读全文
©️2020 CSDN 皮肤主题: 深蓝海洋 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值