🎉 Better Boilerplate by Not Quite Unicorns - Our take on what a good Bubble app looks like

[georgecollier]

@kuntaykunt

FloatingGroup hidden variables” in reusable elements , rather than using the “Custom States” in the reusable element’s page ?

@georgecollier

Custom states and group variables

Against custom states

We do not recommend using custom states at all. There are a few reasons for this:

• They are functionally inferior to group variables, as they cannot be set dynamically in an elegant way
• They are not as visible as group variables in the editor

In almost all cases, anything a custom state can do, a hidden variable can do better. One notable exception is passing data between reusables.

In defence of group variables

A group variable refers to making a group or repeating group have a data source. That is not to display anything, but is to store a dynamic variable that you can later reference. For example, if you reference an ‘Invoice’ in multiple places on the page, it makes sense that all references to said invoice use the group variable.

We recommend naming group variables as var - [name]. This makes them easily searchable and distinct in your scan flow. It doesn’t necessarily have to be var exactly - VAR might look cleaner to you, and that’s okay. It should, however, be short end easily searchable. var is convenient to type with one hand on the keyboard.

• Group variables are highly visible and can be dynamically set
• Group variables can be placed globally (e.g. in a hidden floating group), or locally (next to where they are used)

Storing hidden variables in a popup or floating group is functionally identical with the caveat that plugin elements generally do not load in a popup, so it would be advantageous to use a floating group. That said, I’m normally in the habit of using a popup which is fine for most use cases, so you do you.

Let’s unpack what I mean by placing a group variable globally or locally.

Suppose we have an invoice page, where we display the invoice’s line items, and also some customer details. The customer details are collapsed by default.

In a popup, we would have a hidden variable var - Invoice. This references the invoice we’re displaying, and would often come from a reusable element data source or property. Also in the popup, we would have var - Line Items which is a repeating group that stores the line items to display. The search constraint would be Do a search for Line Items where Invoice = var - Invoice’s Invoice.

These are global variables that dictate the entirety of what the user sees, hence they’re positioned in a hidden popup where they can all be viewed and managed together.

Now, let’s consider the case where we want to monitor the expanded state of the customer details. I may have a hidden variable right next to the customer details card, called var - customer details expanded. Why? Locating the hidden variable geographically close to where it is used/updated can assist understanding its functionality. You can judge which location for the particular hidden variable is right for you.

How To Build A Good Bubble App (Not Quite Unicorns Style Guide & Development Philosophy)

Not Quite Unicorns Style Guide & Development Philosophy This guide details an approach to building Bubble apps followed by Not Quite Unicorns, the youngest Gold tier Bubble agency. A version of this exists on a Google doc which you may find more readable: Not Quite Unicorns Style Guide & Development Philosophy - Google Docs This guide may be updated, but the forum restricts edits after a while, so you can use the Google Doc as the source of truth. Background Not Quite Unicorns (NQU) …