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.