Variables
Last updated
Was this helpful?
Last updated
Was this helpful?
A variable is a piece of data whose value can change over time. In Bravo, variables are used to populate dynamic content into an app: for instance, display specific information depending on the app user, or get a specific database record to display data in a .
Variables consist of two parts: the variable name and the value. The variable name will be always the same, while the value will change dynamically.
You can learn more about variables in Bravo in the video below.
As explained previously, variables have two parts: a variable name, that doesn't change over time, and a value, that normally changes over time. Setting a variable name is called defining the variable, and it's described in the section below.
There are several places where we can define variables:
Now we have defined the variables by indicating a variable name in our API request. However, we're still missing the value for the variables. How can we connect both parts?
Values for our variables can be obtained from several parts.
When an API request is executed successfully, a response message is received. This message can contain some data. The data items that we want to use can be selected in the “Received Data” section:
Then, in the “Selected Data” section, each data item can receive a name. This name is set to a default one, but it can be edited when needed:
Once all these items are selected, they’re exposed as variable values. What does this mean? They can be used in other API requests as variable values, as long as the data item name (specified in the “Selected Data” tab shown above) and the variable name match. They need to have exactly the same name, including uppercase/lowercase.
In order to “pass” these values from the request where they’re received, to the request where they’re used as a variable, the two requests must be bound to UI elements in the same screen, or in different screens connected with a prototyping link in the design file. In case the requests are bound to screens that aren't linked in the design file, the values won't be passed.
For instance, in the list and detail page example, the following occurs:
A GET request is triggered to retrieve data for the list items. In this request, an item ID needs to be selected. Let’s say it has the name id.
In the design file, the list container in the list page is connected with a prototyping link to a detail page. This way, when a user presses on a list item, they navigate to the detail page. Also, this link enables “passing” the value of the id from the GET list request to the requests bound to the detail page.
A GET request is used to obtain the data for the detail page. This request will normally obtain a single database row (the one corresponding to the list item the user chose before). The request will need to have an ID value, so the backend knows which row to return. Since we exposed the id data item in the GET request for the list, we can use a variable ${id} in the detail GET request URL, that will receive the ID of the item the user chose in the list page.
The API request URL targets Airtable in this case. The request structure might be different depending on your backend, but the variable data will be passed in the same way.
We can define one or more variable values in the remote action tag as shown below:
[action:remote:var1=value1;var2=value2;var3=value3]
Here, var1, var2 and var3 would be the variable names, and value1, value2 and value3 would be their values. Both numeric and text values can be used.
Then, if we bind an API request to the remote action, we could define variables that receive those values: in this case, ${var1}, ${var2} and ${var3}. As indicated in the previous section, those variables can be defined in the request URL, body or headers.
Note this only works with strings, not booleans or any other data type.
Finally, another way to give a value to a variable is using test values inside an API request in our collection. We’ll need to do this if we want to test a request we just created, to see if it works properly, and select the data we need. Note that this test value won’t be passed to the variable when using the app - the variable value will be determined with one of the methods described before.
In contrast to user-defined values, built-in variables are special variables whose value is filled in automatically by Bravo. This includes user and device IDs, geolocation data, and more. You can learn more in the link below.
In Bravo, variables are defined with the following notation: ${VariableName}. Here, VariableName would be the variable name, and it’s defined by us - it can be anything we want, unless we use a . Note that the variable name must always be surrounded with the two brackets and the dollar sign: ${}.
Sometimes, the backend requires some input data to be able to return the information needed. In the example, for instance, we’ll normally have a API request that requires the record ID as input, to return the data only for that table record (the one we'll use in the detail page).
Another use case could be sending a to the backend, for instance, to return information based on the user or device ID.
Besides request URLs, variables can also be included in the request body or in the headers. An example would be a POST request sending to the backend.
Another way to set the values of a variable is binding them to an input field in a . This way, in case we have defined some variables in the body of the request bound to the form, we can bind them to the Input Destination property of the different input fields. In this case, the variable values will be the data introduced by the user.
With a , an API request can be bound to a UI element in a screen. This way, when the user presses this UI element, the API request is triggered.
