🚀 Efficient empty state management in a Bubble app (with 0 WU usage)

Tips
1

Hello, amazing Bubble community! :wave:

Ever wondered how to manage empty states in your Bubble app efficiently without consuming a single Workflow Unit? Our latest article dives deep into this crucial aspect of app development. :rocket:

:globe_with_meridians: Why It Matters:

Efficient empty state management enhances user experience and app performance. Learn how to implement this crucial feature seamlessly.

:point_right: Curious? Read the full guide here.

:movie_camera: If you prefer video format, check this video guide.

Option 1: Checking “:count is 0”

Probably the most popular approach is to check if “:count is 0” for the list items inside the repeating group, and display an empty state if this condition is true.

However, this option is the least efficient and consumes the most WU (3.8 WUs per 1000 items in the list, as per AirDev report here. It’s caused by a bug in Bubble code, that leads to consuming so many WUs.

:bulb: Note: if you change the condition to “:count < 1” — it will consume only 0.2 WUs per 1000 items.

Option 2: Checking “:first item is empty”

Probably 2nd most common approach is to check “:first item is empty”. Meaning if the first item is not there — then the list has no items at all.


This approach consumes 0.69 WUs per 1000 items. It’s better than “:count is 0”, but worse than “:count < 1”.

We’d like ideally to not consume any WUs at all.

Option 3: Place the “Empty view” behind the Repeating Group

We can design our layout in a way that we won’t need to add any conditions at all. For example, we can group our Empty State and Repeating Group inside a “Alignt to parent” container and put the Empty view behind the Repeating Group.

Check “Behind” tab in the application.

Such an approach won’t consume any WUs (cos we don’t have any conditions at all).
However, it will work ONLY in the following cases:

  1. When the list item doesn’t have a transparent background (cos otherwise empty view will be visible behind).
  2. When the height of the first list item is bigger than the height of the empty view.

In other cases, the Empty view behind will be visible or partly visible. Plus, there might be a small blink during the first load (when the list items are not loaded yet).

Option 4: Place the “Empty view” behind and add frontend-only conditions

We can improve our previous cases by adding some conditions that will allow us to have any kind of empty views behind, regardless of the size or background of the list item.

For it, we’ll need to make our Repeating Group “Fit height to content” (in the “Layout” tab). And the following conditions:

  1. Page loaded above fold (it waits for the initial page to load)
  2. RG: is loading is no (it waits for the RG to finish loading)
  3. RG’s height < 10 (it checks the height of the RG. If no item — its height will be zero (or a very small number).

If these conditions pass, you now have full control over your empty state, don’t consume any WUs, and provide your users with a snappier experience (since your app makes fewer requests).

This approach can have a meaningful effect if you have many rows in your database or many repeating groups on the page.

In any case, measure and check what works best for your app and use the approach that suits you best.

Conclusion

Bubble is a powerful no-code platform. However, by not following its best practices and not understanding how it works, you can easily overload your Bubble app with redundant requests. Follow these best practices to improve your apps’ performance, and speed, and save costs on less WU consumption.

Hope it helps :raised_hands:.

Links to explore:

The Demo Bubble app link (username / password: “test” / “test”)

Bubble Editor app code

For an enhanced upgrade to your Bubble app, explore our Natively no-code development tool, which effortlessly converts Bubble apps into Android and iOS versions, ready for quick publishing on app stores.

Feel free to drop your thoughts, questions, or share your experiences with optimizing empty states in your Bubble apps. Let’s spark a conversation!

:gear: Explore, Implement, and Elevate Your Bubble App Development!
Happy Bubbling! :rocket::large_blue_circle:

5 Likes
2

Shouldn’t the second identical search not cost anything?

If I have an RG that Do a search for Users, and a condition on another element when Do a search for Users:first item is empty, shouldn’t Bubble only run the search once as both searches require an identical search and first item is empty is measured on the client side? I always thought that’s how it worked, would be disappointed if Bubble treats those as two searches for WU


Edit: After some testing, Do a search and Do a search:first item does run a search only once but is charged twice for WUs. Wack. Additionally, an RG with Do a search for and a conditional expression ‘This RG’s List:first item is empty’ runs only one search (for performance), but is charged twice for WUs. So, it’s speedy but expensive. Why exactly does Bubble charge this twice? RG’s List has data loaded already - referencing RG’s List doesn’t get any additional data from the DB or run additional searches - this has already been done :confused:

2 Likes
3

@georgecollier if the search is identical — then yeah, Bubble should (although I’m not 100% sure) not repeat it.
But in case of empty state management and :count or :first item is empty conditions — these are not the same searches. The Do search is a request to get a list, and :count or :first item is empty is a different request.
Plus, if you have filters in the app (search box, dropdowns, etc), these searches will re-run, and conditions too. Or if the DB changes (new items added / deleted), the searches / conditions will re-run too.

1 Like
5

I stand corrected, now I need to decide whether the WU savings are worth spending time on :sweat_smile:

1 Like
6

Just in the name of justice I’d like to mention @adamhholmes post about :count is 0 bug and also comparison between :count is 0 / :count < 1 with :first item is empty here:

Also, I have a question for option #3 and option #4. Is it worth to rely on the elements layout settings (height, position behind) in terms of optimising WU consumption?

2 Likes
7

Up to you to decide. Can be case-by-case. IMHO in many-many cases just option 3 will work without any conditions and without any problems.

But when I see in WU consumption that the simple “empty state” condition (with :count or :first item) takes almost as much WUs as the search itself — IMHO it’s too much
 (and a bummer Bubble doesn’t provide an optimal way to handle that).

8

Completely agree. I just contacted Bubble to work out what’s going on. The manual clearly states that WU is charged, among other things, for searches, returning data from the database etc.

The repeating group does the search and returns the data. Once. This RG's List:first item is empty should not invoke any WU costs according to the manual. The data is already on the page (as shown by the network tab only making one search) and there are no other relevant costs in the ‘What contributes to workload?’ page.

It’s not even a case of ‘being fair’ or ‘is this cost reasonable’ - it’s that this shouldn’t be a cost at all according to Bubble’s own docs :confused: Thanks for highlighting this because I’d never noticed.

6 Likes
9

Could you share you setup?

My scenario:
1 RG on a page with a Do a search expression with constraints that leads to 0 matching results. Visible on page load.
Here are results for 2 different conditions:

  1. This RG's List of Things:first item is empty → 1 search request → 0,31 WU for fetching data (page load WUs excluded)
  2. This RG's List of Things:count < 1 → 1 search, 1 aggregate requests → 0,51 WU for fetching data (page load WUs excluded). So it’s 0,31 WU for search and 0,21 for aggregation.
10

Load the page 10 times or something and you should see equal WU usage for Do a search for and This RG’s List:first item is empty

My thought was that Do a search for should charge the WU, but This RG’s List should not.

11

Maybe raise this as a bug with Bubble? This thing should indeed not cost any extra WUs.

1 Like
12

It surely SHOULDN’T cost any extra WUs but does that mean Bubble would think of it as a bug? I wonder what % of ridiculous WU spikes shouldn’t even be considered WU usage (e.g., @mitchbaylis and his insane, unfortunate overage charges)

1 Like
13

To update on this, I’ve been speaking to Bubble support and it’s now been forwarded to engineering team so awaiting a response but will post updates here (or a new thread depending on the answer). To summarise, the current behaviour is that if you have an RG with Do a search for and a conditional that’s This RG’s List of X:first item is empty, you’re charged the WU for two searches instead of just the Do a search for which is what I’m trying to get clarification on


3 Likes
14

I eagerly await my refunds :moneybag:
 just in time for black Friday
 :gift: :shopping:

1 Like
15

@andriy.bas thanks for the though provoking article. This is what I normally do, since its based on the list in the repeating group id assume its no WU right?

image
image1444×439 44.6 KB

btw, how do you find out what WUs are being used on searches like that? My logs only show workflows I think.

16

@bkerryk, it uses WU.

17

oooft. Cheers. Might be a bug it seems. So how does one see the WU logs on conditionals like this?