I was doing some tests and noticed that, if I load the data that I need (already filtered and manipulated from my database) previusly in a RG and point my “searches” and operations to this RG instead of use a bunch of “Search for” spreaded all over my page, my app runs smoother and I have almost no lag/load time.
So, my FIRST question is:
This make any sense? Someone else is doing things this way? What are the best practices when we talk about this comparison.
This said, here comes my SECOND question:
Is it possible to hold the loading process of a RG untill I want it to start? Like “don`t load the list untill I am sure that the user will need it”. Perhaps, start the loading process thru a workflow event of something… I tried to make them invisible but noticed that they still loads the data even when they are not “visible on page load”…
And, for last, my THIRD question:
Can I access all data in my RG’s list even if it is not seted as “full list”? Note that I am not trying to show the data, only to access it thru workflow and searches…
Answering my SECOND question for those who have the same doubt…
Yes! I found this option in workflow’s actions. So, I start my RG with an empty “Data source” and fill it only when I need it thru the “Display list in repeating group” option in my workflow. Sweet.
Is a practice of what could be called clever “bubbling”. RGs are renamed to “data - things” or “var - things” … that way you find them easily when building expressions. Also, you place all your “variables” in a popup that you never open on every page. Popups are always loaded to the browser and you keep these nicely in one consistent place. Consider that this practice of setting or pre-setting data onto elements can also be used for single pieces of data (a “var - thing” group of type number, or type date, or type object of any kind in your dB. Going further you can also set a y/n expression in a “var - is this true?” group and use it to make logic building much much easier in other places like flows, conditions, etc etc)
Yeap … “display” is one. Another one is conditions in the RG where you set different data sources (… diff search expressions).
It is nice to discover that I am not alone and, most importante, going in the right way. I will keep doing these tests…
Correct me if I am wrong here…
But one thing that I think is important to put on the table here is that, as I read in the book “The Ultimate Guide to Bubble Performance” written by @petter (and indicated to me by @cmarchan), operations made in these lists (like group, filter and etc…) are processed in the user-side, and operations like “Search for” are processed in server-side. So it is clever to have it in mind when we think about performance, once manipulate a large amount of data in the user’s browser could be bad regarding user experience.
That’s why I am trying to load all the data that I need into my RG as filtered as possible, so I don’t overload my user…
The conventional wisdom after much time learning from knowledgeable folks in this forum (my understanding of it). And through my own experience building apps is to:
build light objects
minimize list fields (only when less than 100 entries), only use them purposefully
relate objects indirectly but both ways when necessary
preload searches
feed from preloaded searches
avoid inflow searches (… hence preloading them)
mnimize back and forths between client and server
use custom events extensively
schedule custom events when full data is needed within steps
use backend when processing is not needed immediately
recursively process key data
And more stuff covered mostly by @petter great guide, as well as, many other talented folks
and, most importante, going in the right way. I will keep doing these tests…