So in this lesson, we're going to learn how to implement this really common user experience pattern where the user is going to land on some page that would otherwise display a list of things — like a list of photos, a list of reviews, a list of activities.

This is the AllTrails app. We've looked at this a couple of times already — social media for hikers essentially — and we have some message appear here on the screen with a call to action to essentially create our first thing from that category.

So we're going to do the same thing in our app for the user to create their first trip. What we need here is some kind of group that's going to hold our empty state elements whenever no trips have been created.

We need a place to add that group. Since we are here on a vertical list view type, we only have two places where we can add a custom design. If we select this vertical list trip element, you can see that we get this little button to add a header group, and we've got another one down the bottom for a footer group. These are the two areas where we can add completely custom designs.

So I'm actually going to add here a header group, and it's always a good idea to just put a group in here which is then going to hold all of the interior content. It doesn't need to have a minimum height either so that it can just collapse to whatever the height of the content inside is.

I've actually got here on my clipboard — if I go and hit paste on group header — I've got an empty state group that I've prepared earlier. Nothing fancy here: we've got an image element with an image that I just generated with ChatGPT, which I have converted here to a WebP. That's going to reduce the size of your application and therefore increase the performance speed of your application. Then literally just a text element, button, all inside of a container with a little bit of row gap.

What we're actually doing here is kind of a classic programming thing — we are saying, "If this thing is true, then I want you to do this."

Now, what we've seen in our applications so far mostly is this kind of logic instantiated in workflows. This is one version where the flow of logic is essentially: if something happens — some trigger event like a button being clicked — then do these things. This is logic that you can think of as being performed by some sort of high-level orchestrator. Some trigger event is happening, and then this orchestrator has access to all of these different things it can do: log in a user, show a group, create data in the database, navigate to a tab — all of these actions they have available — and they are orchestrating them in this string of logic.

That's very different to conditional statements, and we already know this from the limited way in which we've encountered them before. This is tab item trips, and if you remember, when a tab is selected, then we're going to change some of the properties — we're going to change the font color, the icon color, and even the icon. So we get this behavior there with our icons.

I want you to think about this kind of logic — these conditional statements — as just being individual elements that are reacting to the state of things. If our workflow logic is sort of top-down orchestration, then conditional statements are bottom-up reactivity — individual elements deciding to change their behavior depending on what else is going on in your app's world.

If we open up our empty state group for a moment and go into the conditionals tab, this is where — if we click "define another condition" — we define one of these reactive rules. We need to write some kind of what we call a dynamic expression that's going to either be true or false — what we call evaluating to true or false. This is what the condition is going to anchor to.

In our case, in the context of wanting to display this group only when there have been no trips created, maybe one of the easy things that we can do is actually just look at this vertical list of trips. This is an element on the page that is technically holding a list of trips — its data source is a list of trips. If that list of trips doesn't have anything in it, well probably in that scenario we want to show the empty state.

So that's what I'm going to add here. I'm going to add that vertical list trip, and what we can do is look inside of this element, look at its list of trips, and then we've got this really handy little operator here called "count." That is what it suggests — it's just going to count up all of the entries in that list. If there have been four trips created, then this count operator is going to give us the number four.

What we can do is grab that count, and then — because this is a number — we're able to do some basic mathematical operations. One of the operators we have is the greater than or less than symbols. So what we can do is simply say: when the count is less than one. When the count is less than one, that is the same thing as saying, "This list of trips is empty."

Then we add one or more properties for the element in question — in our case, group empty state — that we want to change under this condition. Or rather, we're going to set what the value of certain properties will be when this condition is true. That's why Bubble's written this as: when this thing is true, then these things are going to also be true in a sense.

One of the things that we have access to here is "this element is visible" — simply, can the user view this element or not?

By default here — and I'm logged in as one of my test users from earlier who had a couple of trips created — I can see this empty state when of course I shouldn't be seeing it in this scenario, because we do have some trips that exist here. The reason for that is that yes, we're saying that this group should be visible when that list of trips isn't empty, but also if we go under the layout tab we see that we have this checkbox ticked: "This element is visible on page load." That essentially means the default behavior for this group will be that it is visible.

We don't want that to be the case. We actually need to tell this group, "By default, I want you to be invisible," which in turn makes this condition the equivalent of: "Only under these conditions will you be visible — only when that vertical list of trips count is less than one will this element be visible."

If I reload my app here, you'll see that the empty state group is no longer visible. We should test this out as a new user who doesn't have any trips created, and when we do that we see that the empty state group is indeed visible.

The other thing that we should do here is add on this button the same workflow that we had on our previous plus button, which is to open up as a modal the "create trip" view. That's going to let me click this "Start your first trip" in order to show the trip modal. In that case, we probably don't need this plus icon as well.

So what we could do to this floating group holding the button — which I should probably rename as "floating group button" — is add the same kind of logic. We'll say that by default we won't have it be visible, and we'll just add some condition under which it should be visible.

As you can probably guess, that's just the inverse condition that we just wrote. So: when that vertical list of trips count — the number of items in that list — is greater than or equal to one, then we want to show this floating button.

If we test this out now by creating a new trip, you'll see that as soon as that trip was created, our empty state group has disappeared and our floating button has appeared.

Again, note that in our styles — the styles that have come out of the box with our application — a lot of, if not most, of these elements have some kind of conditional behavior already baked into them. What you'll often find when you look at an element like this button is that it has some conditions attached which are actually assigned at the level of the style. So you would modify them here in the styles tab, or if you just wanted to modify that particular element, you always have the option of detaching the style. Then under the conditional tab, you can modify or get rid of those conditional statements directly.

I think our trips view is good enough for us to move on. The next logical thing is we want to be able to click on one of these trip entries and view that trip in a bigger view, where we can see more context and more information. We're going to deal with that in the next lesson.