I am having an issue with the custom state as a list getting set on page load.
This is annoying as I believe I know what I am doing. I have set the page to have a custom state that my repeating group is using as its datasource.
I have set the workflow so that on page load the custom state is set by doing a search of the database for the items required.
However, nothing happens on page load. Even after I do a “pause” before the set state event, nothing happens.
The real annoying thing is that when I use a button to trigger the event of the setting the custom state, it works and my repeating group is populated with the appropriate list of things as I intend.
Has anybody else had issues with a custom state list on page load not working as it should?
If so, is there a fix to this issue or am I experiencing a bug?
I just tested on another app and it works fine…this seems to be because the other app only has 6 items in the list that the search is done for but the app that I have the problem on is a list of over 1700 items
When I use the button to set the state the search takes a few seconds to complete, but if I just simply make the repeating group datasource do the search it seems to populate faster.
Any suggestions on how to avoid this issue as I am attempting to have several R.G. on page for responsive reasons and they all need to have the same datasource and so a custom state seems to be the go to for this purpose, but if I can’t get the datasource to load on page load, how could I accomplish my goal of having all three R.G. point to same datasource as users will be filtering and sorting on page to affect the datasource.
May also depend on your repeating groups. I think full list repeating groups load differently than scrolling groups for example.
Try using a repeating group in a hidden popup as the source?
Thanks @meyerhd2 I will give that a try a bit later. My ultimate conclusion was that the items count is too large for the on page load action to work properly.
I tested with smaller groups and it worked well.
I also found that utilizing the custom state for setting the list to display in the R.G. is slower than setting the data source of the R.G. to reference custom states for filter items.
For example searching for a list of cars, on page load there are all types of brands. When I click a brand and set a custom state as a list of those cars which the R.G. references for its data source, the results are slower to load than if I instead have a custom state of “selected brand” and use the datasource of repeating group to have a constraint that the brand = custom state selected brand.
This leads me to believe there will eventually with more testing of various ways to call the data and utilize filters and sorts, be a “most efficient” way that I will end up using.
Looking forward to seeing how the hidden popup R.G. works out.
Probably true. So using a repeating group (in a hidden popup) to load items will only load the portion of the list that is needed for the page, maybe.
As part of the list to display is coming from custom states used to set up pagination and give users the ability to set the number of items to display, the list can start small on page load, like 24 items when I set the datasource to do a search for and numbers from and until taken from the custom states.
This helps with page load speed. Overall I’m a bit worried about the speed of items loading as the user clicks through on pagination and I have the list getting reset since custom states are getting changed as the user clicks through.
I think that I will utilize the ability to set a blurry background like a popup with some random facts to give a sense of content while user waits for it to load in areas I know will take a bit longer than acceptable.
May be totally off base here, but I suspect that Bubble somehow prioritizes/optimizes queries/page load on the backend for repeating groups and your custom state list does not benefit from those optimizations, at least that’s what your observations seem to suggest:
So those were the thoughts behind my suggestion: use a single repeating group (hidden, probably full-list type, with constraints set via your other custom states/workflows) as the source instead of the custom state list. All the viewable repeating groups on the page can use the hidden repeating group’s list as their source while applying any other necessary constraints however you do that.
I am also very curious to know if there is a measurable difference on page load and subsequent page actions between using these as a source: repeating group vs custom state list vs regular group (with its datasource being the same search).
Of course it may also turn out that even if there are measurable differences, they are all still too slow for your taste/use case!
@boston85719
Hello
I’m curious…between the 3 repeating group source options elaborated by @meyerhd2, which option was quickest for you in the end from a data loading perspective?
- list stored in custom state
- each of your 3 RG directly referencing the database
- each of your 3 RG referencing 1 RG stored in a hidden pop up
Many thanks!
I don’t use any of the options mentioned in this thread as I figured a way that works best for me and is the quickest way to get data loaded, especially for pagination purposes.
I put RG on page that are set to fixed number of cells with 0 rows and 0 columns. I have multiple of them on page for the purposes of sorting. So each R.G. is “do a search for thing: sort by option”
Then I create another RG (#2) with same set up to put together conditionals for when to use each of the pre-sorted RG as the data source based on the sort option selected.
Then I create another RG with same set up but use the RG #2 as the datasource to set up filters…I label this RG Pagination.
Then I create another RG (RG Display) with same set up but use the RG Pagination as the datasource and put items from items until on there to be used for pagination purposes.
Then the RG I use to display data on page has a data source of RG display set to full list.
This allows me to get the fastest results to load and display data without getting any debugger messages referencing data download issues, and results are displayed quicker than any other method I’ve tested.
Also don’t need to use the vert scroll or ext scroll options which really hamper my ability to design a search results page properly.
1 Like
ListShifter plug-in maybe a good option. it has pagination (i haven’t used this feature) but i use it to load data that is used in multiple places.
then you can manipulate the list as needed.
it is a little hard to get to understand but its worth the time. i have used it to do some very complex operations and the speed is very fast.
