Why is my element collapsing?

I’m having a little difficulty understanding why the following groups are collapsing:

The groups look like this normally:

  1. At the top level: There is a repeating group with a single column.
    1.1 Then there’s a “Lane” container which is the light horizontal box with rounded corners.
    1.1.1 Then inside there is a Lane header that holds the icons.
    1.1.2 Below that there’s another repeating group (1 row, 8 columns).
    1.1.2.1 That last repeating group holds the card elements.

I have no problem as long as there are cards in the element 1.1.2.1, but when I initiate the session, there are no cards in the lanes, and what happens—it seems—is that the repeating group is collapsing.

Here’s what’s happening:
Game Lobby #BFII8I

The lanes seems to load as expected, and then they suddenly collapse. According to the inspector, the heights of the lane and repeating groups inside those is as in the editor.

I’m not sure to understand what’s going on.

I would like the lanes not to collapse and remain empty while there is no cards in them.

What can I do? What’s causing this?

RGs do not show data if there is no data to show.

You could consider adding a collapsed-when-hidden-group below each RG that only becomes visible if the RG count is 0. You can set it to a needed height.

Okay that’s what I thought but in the first RG (1) there is a “player” data element, then inside there is the lane (1.1) which is the container for the second RG (1.1.2).

I can understand the second RG (1.1.2) would not show since there is no card data yet, but with the topmost RG (1), there is the player data, so why should the lane (1.1) collapse? I am confused as to the behaviour here :thinking:

Do you mean that they are nested?

That’s right. I added a diagram to explain the layout better in the OP,

Lets experiment.

Hack:

  • Create a list on the page with a set of player/cards (you know your dB so do here what makes sense). Do this on page load and set a condition for the RG to get its data source from there. Perhaps show “unplayable” cards … just as placeholders.
  • I see that when a blue button is clicked … cards are loaded. I guess this is how the game gets started. Try changing the rg source of data to know get it from the dB instead of the page load list state.

Does this make sense?

… This is an approach using data instead of solving the UI collapsing problem via alternative elements to achieve your desired result (which could be another hack in case the one above does not work to your liking).

Just a suggestion…

I’ll try that.

But, imagine i didn’t have the RG cards at all, and instead just the 1 column RG for players. Each cell would have the lane group and header group within right. Then why should that lane group collapse?

I can speculate but it would only add confusion because I cannot see in detail the way the groups are nesting and also how the dB is structured.

Try nesting the RG2 into a group for itself and set it to be hidden by default … and to only be visible if the search for cards is > 0. Let’s see what happens.

Thanks.

So I did a primary test: removing the second inner RG Group with Card Data. The result is as I expected:

And this is how it should look like too.

Secondly, I restored the Inner RG Group Card Data and forced fed some cards. Obviously then then cards are showing and the Group Lane is not collapsed.

So somehow the inner RG group—without data—causes the Group “Lane” to collapse?

So going back to the default setup–without card data in the inner RG Group–we get this:

Isn’t this a bug?

So you mean not getting the cards from the database but from another element’s data?

  • I see that when a blue button is clicked … cards are loaded. I guess this is how the game gets started. Try changing the rg source of data to know get it from the dB instead of the page load list state.

When the page is loaded, the spinner is only trying to load a list of cards, but at that point players haven’t played cards so it’s supposed to be empty. There is no on-page-load so to speak, the RG will only show cards that meet a certain condition (basically who are this player’s cards + are in play).

Just to be clear the objective is to get it to look like this on game start:

Okay I think I see what’s happening now—but I still find it weird:

The height of the Group Lane is equal to the height of the Inner RG Group : Card Data + the distance between that group and the bottom of the Group Lane.

So if I setup the layout as by default:

Then I am getting the problematic result:

However if I increase the distance between the bottom of the inner RG and the Lane:

Then the default height of the Lane increases even as the inner RG is empty:

Is this really the expected behavior in Bubble? Why would the Group Lane resize itself according to its content?

I cannot provide a definite answer. I have noticed that when RGs are inside groups … groups behave differently. That is why I suggested that you nest the RG under a group for itself. I do not know if you tried this.

As far as I understand this … Bubble provides us with a blank canvas unlike other tools that provide container blocks to house data … like Webflow for instance. The groups and elements that we deposit onto the canvas create spaces, behave differently according to their nature and their responsiveness settings, … and all of this needs to be managed.

So … when one creates a “craft” on a white canvas it becomes somewhat of an art.

I recently watched a long but very illustrative workshop on responsiveness by @gregjohnkeegan that I recommend any Bubble enthusiast or pro to watch > How To Do Responsive Design in Bubble with Gregory John

I bring in responsiveness into this equation because it could be the answer to this predicament.

Perhaps adequate grouping may be the answer.

Or … just by the nature of RGs being nested bringing about this behaviour … you may have to resort to adding dB or page data to them dynamically.

My two cents.

Hello,

So eventually, what I did was moving a “cell” element to the bottom right corner of the “lane” group, so as to force it to keep its height, like so:

As a result, the lane does not collapse:

This solves the problem, however I still would like to know whether that’s the expected behavior and–should it be the expected behavior–whether there is some documentation that could help plan and predict such behavior.

@emmanuel is there maybe someone on the team that can perhaps provide some insights?

Thanks @cmarchan for thinking along.

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.