add exec to ui5 controls to boost performance for data retrieval from many ui5 child controls#456
Conversation
…eval from many ui5 controls
|
🚀 you're clearly on a 👨💻 spree here @philippthiele 🔋 ¡excellente! |
|
Hi, nice feature. Good Idea ! Maybe a name like I added some performance testing to your test file. Resulting in roughly bisection of execution time. 👍 for that. |
|
@dominikfeininger let me know which name fits best to your conventions, I will adapt or you can also do yourself, as far as I know I have enabled edits for maintainers 😊 |
|
Hi @vobu @dominikfeininger , |
|
This would help a lot, would be great if this could be merged. 👍 |
Siolto
left a comment
There was a problem hiding this comment.
some node version problems rest looks good. @vobu @dominikfeininger we still want to support node 14, right?
examples/ui5-js-app/package.json
Outdated
| }, | ||
| "devDependencies": { | ||
| "@ui5/cli": "^2.14.10", | ||
| "@ui5/cli": "^3.1.1", |
There was a problem hiding this comment.
ui5 tooling v3 requires at least node version 16. Currently we still need to support node 14 that's why our tests are failing
There was a problem hiding this comment.
agreed, let's put this on a separate PR to both drop node14 and upgrade to ui5-tooling 3
examples/ui5-js-app/package.json
Outdated
| "dependencies": [ | ||
| "ui5-middleware-simpleproxy" | ||
| ] | ||
| }, |
There was a problem hiding this comment.
why do wee need these dependencies?
package.json
Outdated
| "@typescript-eslint/eslint-plugin": "^5.42.1", | ||
| "@typescript-eslint/parser": "^5.42.1", | ||
| "@ui5/cli": "^2.14.14", | ||
| "@ui5/cli": "^3.1.1", |
There was a problem hiding this comment.
same here we still test wdi5 with node 14 as well
|
Hi @philippthiele, great work and nice idea! Looks like this could boost up test execution quite a lot. From my point of view technically this looks fine. Just some minor remarks from my side. Documentation, fixing the tests and naming alignment is open I guess. |
| viewName: "test.Sample.view.Main" | ||
| } | ||
| }) | ||
| const buttonText = await button.evalOnControl(function () { |
There was a problem hiding this comment.
what do you think of dropping the function() and return part of evalOnControl() to look "cleaner" similar to this:
await button.evalOnControl( getText() )
// or
await button.evalOnControl( this.getText() )
// or
await button.evalOnControl( button.getText() )| // ********* | ||
| // new approach -> takes ~4.3sec | ||
| marky.mark("evalOnControlForListItemTitles") | ||
| const peopleListNames = await list.evalOnControl(function () { |
There was a problem hiding this comment.
similar to my suggestion above:
await list.evalOnControl( getItems().map( item => item.getTitle() )There was a problem hiding this comment.
this would even allow to dynamically change the return type, à la
// have an object returned with an embedded array
await list.evalOnControl( { getItems().map( item => item.getTitle() } )| } | ||
| } | ||
| const peopleListData = await browser.asControl(listSelector).evalOnControl(function () { | ||
| return { |
There was a problem hiding this comment.
just for completenes' sake:
browser.asControl(listSelector).evalOnControl(
{
tableTitle: getHeaderText(),
peopleListNames: getItems().map((item) => item.getTitle())
}
)|
|
||
| //special case for evalOnControl, passed function needs to be converted to string to be passed to the browser | ||
| if (methodName === "evalOnControl") { | ||
| if (args[0] && typeof args[0] === "function") { |
There was a problem hiding this comment.
this would of course then have to change when we change the API
|
Here are my .02€: 👀 I left some comments on the way the API looks - let's try and reduce it to the bare minimum. Mind you, my suggestions are suggestions only → open to any kind of mods that make 📛 That having said, I'd vouch to change the method name to ✍️ Additionally, and as @Siolto has pointed out, we'd need documentation on this please 😸 again emphasizing that this is a great improvement! thanks for the work you put into this so far! |
|
@vobu
Rename method to exec: done Documentation: Will do when everything is clarified and implemented 😊 |
ah, of course, didn't have this on the radar!
👍
👍 please also don't forget to downgrade |
|
@vobu I have update the chromedriver in the package lock which fixed a few tests, rest does not seem to be related to a package or the changes in this PR though. Can you help check what is wrong? Also: I have extended the functionality to accepts arguments as well, as we were talking about anything being possible with a function, passing additional arguments makes sense I would think 😊 Reminder for me: I should check whether propagating errors is possible, to make debugging easier when a browser side error occurs, like calling a non-existent function like "button.getTex()" |
sure, I'll peak and see what I can fix. Let me get back to this as soon as I can.
¡excellente!
absolutely, nothing beats DevX improvements. |
|
@vobu documentation is added 😊 Finishing line is in sight. Please let me know whether something is missing/can be improved! |
|
Might be worth to check if a general support of direct injected code into browser scope find it's users. const fn = () => {
// since the RecordReplay API etc. is available a full blown test execution would fit in here
return sap.ui.getCore().byId("container-Sample---Main--Title::NoAction.h1").getText()
}
// this code is in wdi5 and could be provided via eg. `browser.execUI5()`
const result = await browser.executeAsync(function (fn, done) {
done(eval(fn)())
}, fn.toString())
expect(result).toEqual("UI5 demo")-> next PR |
w00t! I'll re-review asap, also pinging @Siolto and @dominikfeininger to glance over. |
vobu
left a comment
There was a problem hiding this comment.
this. is. so. cool.
there's a small typo (suggested a change).
and i left a hint how to optional test for error messages relayed from browser- to Node-scope, as we have this in a test already.
I'm stoked to see this go in once it has the +1 from Dominik and Simon
|
|
||
|
|
||
| it("should be able to propagate a browserside error", async () => { | ||
| //Log Output during this test should be 3 times: [wdi5] call of exec failed because of: TypeError: this.getTex is not a function |
There was a problem hiding this comment.
optional enhancement: you can validate error messages on the console in the Node.js scope with the help of sinon.
See
| expect(buttonTextArrow2).toEqual(regularBtnText) | ||
| }) | ||
|
|
||
| it("execute function browserside on button to get its text with fluent sync api, basic return type", async () => { |
There was a problem hiding this comment.
small typo
| it("execute function browserside on button to get its text with fluent sync api, basic return type", async () => { | |
| it("execute function browserside on button to get its text with fluent async api, basic return type", async () => { |
|
this. is. so. cool. |
|
@philippthiele we'll of course announce the new version with this excellent feature, but would you also care to blog about it on blogs.sap.com? Pretty please? 😸 |
|
@vobu I will not be able to produce an adequate blog post before my vacation, I will be happy to pick up the topic afterwards 😊 |
|
all good! enjoy your time off and recharge properly! looking forward to reading your blog post after your vacation 😄 |


Note: documentation is still missing, please let me know what you think of the PR and whether something can be improved, before I start documentation efforts. Thanks!