Closed uxkjaer closed 10 months ago
marianfoo
commented
2 years ago Hi Jakob, can you tell me exactly how you trigger this bug. I could not recreate it exactly like you, but similar. Something doesn't work right here with "growingScrollToLoad", could be an openui5 bug. Thanks for reporting.
marianfoo
commented
2 years ago same behaviour in Chrome, Firefox, Chrome Mobile
uxkjaer
commented
2 years ago I am using vivaldi as my browser. I'll check on Chrome today.
uxkjaer
commented
2 years ago hmm seems to work now. closing
marianfoo
commented
2 years ago can confirm bug is still there to recreate: Open bestofui5 --> go to "All Packages" --> go pack to "Hot Packages" --> scroll to load does not work
wridgeu
commented
2 years ago Hey everyone,
I've taken the liberty to debug some of this behavior and tried to get to the bottom of it. I'll be documenting what happens here on a technical level as well as what I think could be the root cause of this.
Since all of this is quite specific to the way the app is built and also has to do with framework internals/handling I can't tell for sure whether or not any of this is "right" or to what degree I'm actually touching the right places here. Feel free to correct any and everything.
The scneario I've been looking at (which is also the way to reproduce this issue) is as follows:
When you refresh/load the page:
→ You'll be on Hot Packages initially → navigate to All Packages → navigate back to Hot Packages → scroll down
You can scroll on All Packages and additional list items will be loaded as expected but when you're back at Hot Packages this does not work anymore, you won't get any additional items added to the list, it just stops (breaks).
In the Chrome-Dev-Tools I observed the following:
When we go to Hot Packages View, we can see the initially loaded 12 items in our DOM, ending at __clone11:
... which is the same as on All Packages where we can see the initially loaded 12 items ending at __clone31
Now it gets interesting though! When we're navigating back to Hot Packages and scroll down we expect to get more items added to our currently displayed list (which is Hot Packages View) however, what we can observe instead is that another 12 items get added to the All Packages DOM: __clone32 to __clone43
Why is it though that we don't have duplicate entries in our list when we now go back again to display All Packages? Well ... our 12 wrongly added items are getting kicked out of the DOM which we can see by having a cut in the DOM now: at __clone31 it starts wtih __clone44 and all in between (the previous 12) are gone.
At first I noticed that in the method requestNewPage of GrowingEnablement.js, the content of this._oControl references the All Packages list during our scroll in Hot Packages.
Why could that be? I debugged the constructor of GrowingEnablement to check whether this gets filled correctly and if its called twice (which I would expect, since we have two lists that can grow). Well, it does get called twice and it does get set correctly so whats wrong here? I thought I'm just at the wrong place and continued analyzing further until I stumbled upon the following callback: this._fnScrollLoadCallback() in the _onScroll function of ScrollEnablement.js → docs / api. I thought "this has to be set somewhere, right?" → It does: in setGrowingList the callback function will be set. So ... when does that happen?
Apparently this happens within our known friend: GrowingEnablement.js in it's onAfterRendering method:
This onAfterRendering happens twice in our above mentioned scenario. Once for each time the Views get rendered and as the last rendered View (list) is All Packages, the callback function that is set handles the addition of items to our All Packages list. When we're navigating back to Hot Packages now and scroll down our _onScroll gets executed and in turn will call this callback function which adds items to All Packages instead of Hot Packages.
What I also noticed is that the oScrollDelegate of each control is the same, our rootView. So if I get this right the GrowingEnablement registers itself (coming from each List) to the rootViews scroll delegate in order to react on scroll events and have these events (or its handling) passed down from the root accordingly to the list in order to load more items.
When you refresh/load the page:
→ You'll be on Hot Packages initially, this renders the Hot Packages list which creates/uses the GrowingEnablement this in turn registers itself and how to react to scroll events to the "parent" (wherever we can get the knowledge from when someone scrolled) → hereby we set a callback function that is to be called in order to render more items to our list
→ navigate to All Packages, the same as in Hot Packages happens, which causes the callback function that was set previously (within ScrollEnablement) to be overwritten with the appropriate callback function for All Packages
→ navigate back to Hot Packages → scroll down → the callback function of All Packages will be executed
I feel like this could be prevented in some ways. Of course only if anything I wrote is even remotely true or makes any sense at all😅.
clearAggregation/clearTarget in the router config however, we're using the NavContainer for which the documentation shows the appropriate use would be to have it on false so the default config for sap.m.routing.Router. And in my experience using this at all is, from a performance perspective, quite ugly.ScrollDelegate internals here using the getScrollDelegate method of sap/m/library which returns the corresponding ScrollDelegate instance for a given control. This though is quite "ugly" although it works (more or less well) with some gluecode. I sadly have no "real" fix as of now and continue thinking about it. Hope any of the above can be of help! 🐢
[Edit] Also found this old but still interesting/helpful SO post
Check out the gif.