Over the past few days I’ve made a number of changes to my app, most of which I didn’t document in any meaningful way (other than “fix x”). Yesterday I noticed that when clicking on an item to launch the detail screen popup, it now is very slow in displaying the popup window, almost like it has some fade-in effect applied to it.
Any tips on how to troubleshoot this? I.e. likely causes for that particular action being very slow?
Is it just a “show details screen” action or do you run any thing else in that action to launch the detail screen?
How complex is the calculation for everything involved in that details screen?
So the action to launch the detail screen just has one other function besides show detail screen, which is that it writes a value to the user table that needs to be referenced in the detail screen. The details screen does have a number of visibility conditions set for various components, some of which are based on whether a relation is empty or not, a relation that is looking at that value in the user table.
Edit: One other thing, testing it now in a different browser it’s slightly faster in Chrome v. Safari…
What happens if you reverse the order of your action so that you’re showing the detail screen first?
So in my action, show the detail screen, then write the value? Let me try that.
Hmmm… I tried that and I added a “show notification” to the end to be sure that the revised action is the one loading in my browser.
In the builder the show notification displays before the detail screen even begins to appear. But that leads to a related question/issue. Although I cleared the cache in both browsers, the show notification does not display in the actual hosted version of the app, which suggests that it’s not loading the updated action…is that right? and if so how do I fix that…
Ok, Now that I’ve tested it in both browsers @Robert_Petitto, that didn’t solve the problem but wondering if that is a clue.
Ok…I think I found the culprit. A big table with a “group by” that was loading a lot of groups, each displaying their first 24 items. Sorry to make you all travel along in my process 
Interesting! Good to know moving forward that GBT with groups can cause UI lag
Sorry. To be clear I didn’t mean Big Table. I meant a table with a lot of data. A small b big table.
You might also want to try current, main or slide in as the target window, those three and especially current and main might perform better than overlay.
Let us know if you test this and notice a difference.
I’m reopening this because now I’m experiencing a different speed issue. Reducing the number of rows that were loading by eliminating the group by helped with the popup opening slowly. But now realizing that when you click the edit button that opens the edit this item window, when typing in th input box it’s really really slow…Like one letter every second… Anyone else experienced that?
Thanks. I did resolve the other issue but have a new speed issue…
Are you loading a lot of components and data on the tab, including hidden components with visibility conditions and tabs? If so, could you try to reduce?
