It helps us a lot to resolve OPA issue if we understand the logic of OPA implementation thoroughly.
Take my Lead OPA for example, in our test case implementation, we simply design several command and execute them
All those command simply assemble an object and delegate to waitFor function:
The waitFor implementation is the essential part of OPA engine. The parameter passed through waitFor is simply inserted to an internal queue maintained by OPA engine. For every item inserted in the queue, besides the properties specified in our test code, there are some additional default properties like timeout : 15 seconds and pollingInterval: 400 milliseconds.
For the test case “Add Lead View Test1”, there are totally 29 items in the queue to be executed one by one. You can check queue content from variable queue in line 298 below.
Remember, our test code will never immediately trigger OPA execution. Instead, the code will just insert directive into queue and return. The real OPA execution is triggered by Opa.emptyQueue, see line 73 below. The directive in the head of queue is fetched via Array.prototype.shift, and internal polling is started via internalWait.
And below is the core of OPA queue handling engine:
When you study OPA source code, you will meet with many usage of promise & resolve & reject in the source code, this is also the case in our latest UI5 framework. See this article for more detail.
要擷取更多Jerry的原創文章，請關注公衆号"汪子熙":