Loading animation while repeating group loads

Loading animations are the bane of my existence. I can ever get them to work. Somebody help, please please please.

I don’t want to use a plugin.

All I want to do is show an image (which is an animated svg) until the items in my repeating group are visible. But I can’t figure out a conditional that actually works.

I’ve tried:
CleanShot 2023-11-16 at 18.53.14@2x

CleanShot 2023-11-16 at 18.53.57@2x

CleanShot 2023-11-16 at 18.54.24@2x

I’ve also tried the janky way of showing the loading animation by default and then adding a page load workflow with a pause and then showing the repeating group after some arbitrary period of time.

Nothing is smooth, nothing works, nothing nothing nothing I’m so upset about this.

Please tell me your ideas, MWAH.

4 Likes

Hello @heythere

Try RG content list of generations count is RG content list of generations count

Hmmm curious solution. Tried it, doesn’t work for me. :confused:

What is your setup? Are these nested RGs? Are you displaying the RG or is it dynamic?

Ugh is right. Loaders often need to be tweaked with janky workarounds so feeling your pain :confounded:
(@Bubble, can we please get an event that relates to the an element being retrieved / downloaded and ready to be displayed? :pray:)

I presume you’re filtering and searching for RG content in the RG on the page itself? If so, I’ve used the following setup which has worked sometimes (and inexplicably hasn’t worked the other times):

  1. Use custom states for list of content (and obv link actual RG content to the state) and display RG content (boolean, default = no)
  2. Do the following sequence in the page load WF:
    a. custom event to set the list of content in the CS →
    b. set state display RG content = Yes (really shouldn’t be using a custom state for this but a reveal / hide action but part of the jankyness is that this seems to do the trick better).

Not nested. Just a regular ol’ repeating group.

I am doing a daisy chain population of the data, though - there’s no data source on the page. When the reusable is visible, it triggers a series of custom workflows that display the data step by step (accounting for any filters that are set).

I will say it’s a pretty long list of stuff (150+). So not altogether surprised that it’s having some issues.

1 Like

I would highly recommend to use the plugin of @bubbleis, because its not natively possible to have an event when RG is rendered, only when RG is loading. (and thats not the same to when its rendered, visible on the page)

This will trigger an event when RG is RENDERED. This is the value which is important for showing and hiding content preloaders oder loading animations.
The only limitation is that it unfortunately only fires once. Only the first time the RG is rendered, not when data changes.

I already submit an idea to implement something like https://blurha.sh/ , but i don’t think that there is any focus on that unfortunately.

Maybe someone can create a plugin for blurhash :stuck_out_tongue:

Would save a lot of a time and even if loading times are not perfect it would create a nice user experience.

2 Likes

I was in your same boat a while back - wanted a decent animation native in Bubble. I gave up and resorted to an alert that appears and stays for a set number of seconds that tells the user their search is being executed.

To state the obvious the ultimate solution is getting rid of the delay. I don’t know if the daisy chain approach is the issue, but FWIW I’ve never understood the advantage of this method.

What’s the conditional on RG itself?!

There are some approaches mentioned in @heythere tweet :slight_smile:
https://twitter.com/ClausISaidSo/status/1725214958080667698

Thanks for this @daviddr17. I installed this and couldn’t get it to behave as expected, unfortunately.

In the end, I feel like this is something Bubble should be able to do without a plugin. Can’t have everything you want, I guess, but I hope the team considers this as an essential feature.

1 Like

Yeah, the problem with this approach is that (I think) the repeating group doesn’t actually start rendering until it’s visible. The list might “load” as far as the data being pulled down from the server, but the actual visual rendering on the page is the thing I’m trying to solve for. A pause doesn’t help, no matter how long it is. Just delays the start of the rendering process.

I’m sure Bubble does this intentionally, to only run stuff when it’s necessary, instead of all on page load or whatever. That’s useful in most cases, but would be nice if we could force the rendering of hidden elements in special cases.

Could be part of the issue, but if I’m right about it not rendering until it’s visible, I doubt it.

And FWIW, I only daisy chain when I have multiple filtering options. Instead of having a bunch of complicated conditionals for each potential combination of filtering options, a daisy chain starts you off with a base list, then pares down the list w/each new filtering option via a separate workflow for each. It’s super fast and much simpler. But yeah, for a simple list or a list with just one or two filters, it’s not necessary.

Yes, neither have I, and I’ve seen more people on the forum recently saying they use it.

What is the problem with using the filters as constraints on the search itself and using the checkbox for ignore empty constraints? That allows the user to select any filter choices in any combination in any order they want and no need to manage a bunch of workflow actions.

I’m honestly asking this as I’ve asked others who use the approach and I have not heard why using the multiple workflows necessary for a daisy chain is easier than using the constraints on a search, or how it might be faster.

I know the idea is to not use a plugin, but a plugin could help make it easier.

Trying to focus on not using a plugin, do you need the loading screen to show after the first load of the repeating group or does it need to be displayed each time the user is making different filter choices?

Here’s what I ended up doing

This is a variation on @sam.morgan’s recommendation, here on Twitter: https://x.com/_sambubble/status/1725316587471638730?s=20

There are lots of good solutions in the comments of my original tweet. Peruse here if you’re so inclined.

Anyways, here’s what I did:

First, throw a parent group on the page. I have it set to column, but doesn’t matter.

Put two things in this group:

  1. The loading animation (in my case, a reusable element)
    – This is visible on page load.
  2. Another group that includes the empty state element and the repeating group.
    – This is NOT visible on page load.

It’s apparently important that these two groups are at the same hierarchy. Unsure of why, I just believe whatever Sam says b/c he’s very smart.

Here are the visibility conditionals on both of those child elements:

The Repeating Group is visible on page load. No visibility conditionals.

Basically whenever the parent group is visible, the repeating group is visible inside it, even if the count of the list is 0.

The empty state element is invisible on page load.

Here is the visibility conditional:

It’s not the very best solution - sometimes there is flashing of the empty state element before the list renders. And if a user filters the list, the loading animation flashes really quickly while the daisy chain is loading the list. But it’s the best solution I could cobble together.

Really hoping Bubble makes it easier to create good UX for an app without having to jump through these hoops.

I :blue_heart: Bubble.

8 Likes

I usually place groups on the same hierarchy (and RGs inside them) and I have not come across these problems in my experience.

As you say @heythere it seems to be what does the trick :smiley:

@sam.morgan great stuff!

1 Like

Not the best solution? Seeme to me more like not a usable solution.

1 Like

@code-escapee the best solution that I could come up with for this is to ditch the conditionals on the elements as they do not work as effectively, and instead use some workflow actions, but this assumes the loading screen is shown on page load.

The loading screen element is a floating group that can cover the entire page, or if needed to show some portion of page can be designed to do so.

In workflow on page load show the floating group.

Screen Shot 2023-11-19 at 11.22.31 AM

Have a conditional workflow trigger for when the repeating group is loading is no, which will run action to hide the floating group (set to run every time so that if the daisy chain approach is used in filtering, which will cause the repeating group is loading to go from no to yes off each user interaction with filter choices the hide/show functionality of repeating group and floating group for loader is consistent).

Then have a conditional workflow to hide the floating group when the repeating group is loading is yes (this is only necessary if the floating group loader is to be displayed each time the repeating group has to filter through daisy chaining causing the filtered search results to have a delay in rendering in the repeating group).

This works perfectly with no unnecessary flashes of elements (at least from my testing). The only time I saw a flash is when I caused the repeating group to change it’s datasource and it reloaded the data in 0.5-1 second.

1 Like

Same - I am curious about the reason why a multi-workflow daisy chain is needed, vs. simply using the “search for” box and checking ignore empty constraints. Aside from a daisy chain being more complex to set up, in a worst case scenario it pulls a server side search to the client side, which eliminates the app’s ability to efficiently filter large amounts of data.

I think this is through the potential use of the :filtered operator within the workflows required for a daisy chain (although I am not 100% sure how the daisy chain approach is implemented, I can only assume). I’d think to, that there is a lot of ‘bloat’ on the client side since each workflow action requires the entire list from one workflow to get transferred to another workflow action so as to filter through the list found from the previous workflows.

I’m genuinely interested in knowing from somebody who uses this approach what their speed test results are that demonstrate daisy chain is faster as they report, mostly because if other developers are doing something that is more performant than what I’m doing, I’d like to know so I can switch the way I develop to be more performant.

I’d take faster performance over ease of development or management of the app.

1 Like