Wait…there’s more…and its better!
tldr: There is an astoundingly simple bubble-only (no Javascript) solution to the problem of knowing when a repeating group is fully-loaded that seems more accurate/reliable than EventListeners and MutationObservers. Also, learn how to use your browser’s console AND USE IT.
Note: my case is a full-list repeating group with unknown number 0-200+ items that is main content of the page (think imessage). It presents a challenge because its fast when it has few items and slow when it has many. Other types of repeating groups may behave differently on load so refer to the detailed explanation to figure out your use case.
Here’s the solution that literally takes less than 1 minute to build, read below for the explanation:
-
Create a custom state on your repeating group, type: Number, mine is named “LoadCount”.
-
Create a new workflow “Do when codition is true”, every time, only when: [your repeating group’s name] is loading is “no”. Here is mine:
3. Add 1 action to that workflow that will add +1 to the custom state you created in Step 1.
4. Add another workflow “Do when condition is true”, every time, only when: [Your custom state’s name] = 2.
5. Create 1 action in this workflow that resets your custom state to 0.
6. Then add to Step 5’s workflow the action want to trigger when your repeating group is fully loaded. THAT IS IT!
Here’s why/how this works:
First on the browser console topic, it deserves a separate thread so I defer, just know its invaluable for solving problems like this.
The real problem with knowing when a repeating group is finished loading so you can then trigger an action, like turning off a “loading” screen in Keith’s example, is twofold:
The time it takes bubble to get the data to your browser (solved above) AND the time it takes the browser to render (which depends on formatting, cpu, etc).
Note that EventListeners, MutationObservers, and my solution are all aimed at the first part of the problem. I couldn’t find an attractive solution to the second part. Here’s the results first:
What is this? Same mutation observer from my post above, plus a couple console logs generated from bubble’s “When repeating group is loading” workflows. BTW this is my message repeating group loading 10 simple messages.
Note the two “slugs” of repeating group loads: YES I’m loading, NO I’m done, YES I’m loading, NO I’m done. The first apparently “informs” the page of how much content is coming, hence, bubble says “Page is loaded” because technically the layout of the page can be finalized.
But the second slug is when the actual data is loaded into the page. Therefore, the simple solution I listed above just counts how many slugs are loaded, ie, the repeating group is really finished loading the 2nd time "[myRepeatingGroup] is loading = no. Looks to me that it is a better, simpler, more reliable solution than configuring and maintaining a plugin (I feel you plugin developers!)
It’s not just conjecture. Here’s the same load with some timestamps added:
Yes, console timestamps/events are not 100% reliable, but this is pretty darn good result given there is NO JS, NO HEADACHE, A COUPLE SIMPLE WORKFLOWS. Here my mutation observer is labeled TESTID1… 400ms difference. No joke, my mutation observer previously had to have a 400ms setTimeout in order to get the result I wanted. The timeout was removed for this test.
Better still, lets throw 75 messages at it and see what happens:
Woah. The bubble method is 3.5secs slower…or is it? In fact, the bubble method almost exactly matches the screen as the messages fill the group. It is the mutation observer that is firing way too early, which is the reason I spent a whole additional week trying to solve this problem! I had to keep adding more delays to the mutation observer to get it to fire when the group was actually finished loading. No more. The simple bubble approach works every time, spot on, with no guessing how long to wait!
Just for fun, here’s 150 messages:
13 secs to load 150 messages? That is highly variable due the second part of the problem, the “network” dependency. I’m only loading 76KB of data here. I was getting significantly better load times earlier in the day. And I was using a somewhat-slow VPN throughout.
Is the mutation observer wrong? No, it’s just not measuring what we want. It fired at the same millisecond that the second slug of data began, ie, the first byte of data received is (correctly) identified as the mutation, not the last byte, which is what we want. This is more obvious with more data as shown above. And recall, my mutation observer is only monitoring the last cell of the repeating group. You may have the chops to rewrite the mutation observer to get that but “y tho”, the bubble method yields the accurate “is really done loading” event that we want.
So there you have it, a simple solution to a complicated problem. I admit that I accidentally discovered the two repeating group loading slugs because, out of frustration, I was console logging every single thing I was doing–shoutout to @keith for continually stressing the value of that approach.
The action “repeating group is loading” has been there as long as I can remember, maybe tried it once and it didn’t seem to work. Only by logging the results did I discover that there appears to be two slugs, always for my full list, and I verified with lots of messages.
Note to bubble: can we tame down the 150 console warnings I get about my full list repeating group?! It is only 68 KB of data. Maybe you can switch that to “only once” instead of “every time”?!