Variables can sometimes feel a little clumsy, but they can make a big difference to simplifying your code. This is especially true if you also use “Detect” triggers and maybe even formula values for your variables.
For example, if you have a password input field you can have a variable that uses a ‘length’ formula to always have the value of the number of characters in the password. Using a detect on this variable enables you to trigger action when the password is 8 or more characters.
Achieving the same effect without a variable is tricky, but there are other good reasons to use variables – you can track their value in Preview mode and this can help you fix errors in your logic. If you rely just on properties of objects, tracking their value can be harder.
The contrasting position is that some classic variables are really not needed – for example, ‘status’ variables for toggling states can sometimes be avoided by simply inspecting the opacity of the relevant object. However, one advantage of using a 0 or 1 status variable is that the opacity of your on indicator can be set to a formula (status*100) which means you only need change the status variable and the change will be shown automatically.
Using a variable can also simplify the construction of conditionals. For example, this Pie (based on one by Alisa) uses a variable called match which reflects whether each password field is more than 5 characters and matches the other field. Using these means that one has one set of simple conditions for giving match a value and another set of simple conditions for responding once there is match (using a Detect trigger).
Inspecting this variable match makes it easy to see when the passwords match and when they don’t. The condition for highlighting the Create Account button simply checks the checkbox whenever the match is 1.
