I’ve been facing a new issue recently and I don’t really know how it can be resolved. Basically, I have a dropdown located on popup which is supposed to show dynamic choices, except they’re being extremely slow to load and appear, around 6s. It may not seem like a lot but to a user it seems like there is a problem and may make them quit the action and report a problem.
I don’t understand how this could happen given that I recently switched to a professional plan, and it should therefore be fine speed wise, in fact everything else is fairly fast/including repeating groups. Is there perhaps a way to make the choices load before the users even click to display the pop up and the dropdown?
Try putting the same search into am element on the main page and style it so the user can’t see it… It needs to be visible (not hidden) as far as bubble is concerned, but you obviously don’t want the user to see it. Bubble will probably cache that search so it will be faster in the pop-up.
You could also run the search and load the results to a custom state on the page, and then in the drop-down, just reference the custom state’s values. This would effectively run the 6s calculation when the page loads and hopefully that’d finish the before the user clicks the dropdown.
Additionally, you may want to check the calculation that you’re using to grab the data. Writing smart, efficient queries improves performance materially.
I use that as well… but only if the drop-down is generally static. If the list of items is more fluid, i think the caching is easier to maintain than refreshing the custom state.
It may be worth investigating your Choices source. (If my understanding is incorrect, please feel free to disregard my points below).
From what I see, this is composed of two parts.
Current User’s Bundles
Current User’s User’s Bundles
If I’m reading correctly, there’s some sort of association of “Users” with the current user (ie. their list of friends, colleagues, etc).
So, let’s say the current user has an average of 50 “Bundles”. Then, let’s say that the user has 25 “Users” associated.
In that case, potentially 1,300 unique objects are being retrieved to populate the dropdown’s values. (Of course, it could be much if the lists are shared). This list is compiled by going to each of those individual users, adding to a larger list, then merging it with the current user. That’s a lot of traveling!
While I also use the state-based approach on occasion, I think that restructuring how you retrieve the data is the more important step. (Especially as your app grows and if your privacy roles become more complex). You should be able to achieve this using a “Do a search” and applying the necessary constraints there versus merging many lists.
Hey Dan, thanks for taking the time to write all of this, I really appreciate it. Actually the ‘Current User’s User’s Bundles’ is just bad naming on my part. Oops… It just refers to the users’ bundles. Though, your comment does not exactly apply here, I really agree with the general idea behind it. I’m nearing completion of the beta version, and I think that after testing, my largest task will be optimisation. This will be a hard, long, and painful process, but nonetheless essential. Again thanks for your advice, as well as @mebeingken and @sridharan.s, you guys’ advice both here and elsewhere has been really useful and appreciated
Figured that’s the case. Happy to offer 2 cents. Congrats on nearing completion on your beta.
From a naming standpoint, I’ve found it helpful to 1) keep my data types to capital letters, 2) for specific fields to be lowercase, 3) to join multi-word names with an underscore and 4) when working with lists, to use a word to mentally signal that the thing is a list.
