Stateful component (like button)

Create components with default and active states
Add toggle elements in your apps! With this feature, you can create components that will have two different states. The state change will happen when the user presses the component inside the app. An example of this would be "like" buttons, but you can create any design you wish for the component.
Each time the user presses the component and the state of the element changes, a remote action can be triggered to keep track of the state in the backend, or to send any data you wish. This is optional, but necessary in case you want to keep track of the states each time a screen with these components is opened, or you want to create lists filtering the elements by their state (for instance, a screen with liked/bookmarked items).
👉 The Tags
These are the tags you'll need in the design file to implement the toggle component. See more information in the next section.
You need to create two components: active and default. If you're using Figma, you can also create variants. See more in the next section.
Add a remote action tag for each state, as shown in the example design file.
[state:default][action:remote]
[state:active][action:remote]
These components must be surrounded by a group with the following tag:
[state-set:{identifier-name}]
Replace {identifier-name} with a name of your choice. For instance, [input-state-set-likebutton].
⚒️ How to set it up
🎨 Design file setup
To create a toggle component, you can:
Use Figma variants to create two versions of the component: default and active.
Create the active and default components separately in the design file, and add Bravo tags to them. 
The result will be the same, regardless of the option you choose. If you're using Adobe XD, you must implement it with Bravo tags.
You can check out our example design file, and adapt it to your own design. In this example, we'll create a like button. However, you can create the design you wish.
You can create a list of stateful components by binding the component you create in the design file to list data. To do that, the stateful component must be inside a container.
Option 1: Using Figma variants
1. Create a Figma component and add two variants, setting their state property to active and default, respectively.
2. Add the two variants into the app design, and create a group around them.
Set the [state-set:{identifier-name}] tag to the group, replacing {identifier-name} with a name of your choice, for instance, [state-set:likebutton]. In case you create more than one different stateful component (for instance, a heart and a thumb), you need to set different names for each of them.
Set the [action:remote] tag to each of the variant items. The remote action will be bound to an API request in Bravo Studio's Data Binding section, after importing the file. This will be covered in the next section of this document.
You'll want to display the default and active elements covering each other, so they both occupy the same visual space.
Option 2: Using Bravo Tags
In case you're not using variants, or you're using Adobe XD, you also have the option to create the active and default elements with Bravo Tags.
   1. Create two separate elements in the design file: one for the default state, and another one for the active state. Group the elements together.


    2. Add the [state-set:{identifier-name}] tag to the group, replacing {identifier-name} with a name of your choice. Add the [state:default] and [state:active] tags to them, respectively. Also, add the [action:remote] tag to both the default and active state elements. 
    3. Finally, add the group in the part of the design you want, making both the active and default elements "cover" each other.
🔌 Setting up the backend and API requests
Managing the stateful components requires the creation of a database that keeps track of the state for each component, and API requests to exchange the information. 
You can duplicate the setup shown here in the Sample Apps section inside the Bravo Dashboard, choosing the Bravo sample: like button app.
Create the backend table
First, we'll need to setup a table in the backend. In our example (you can duplicate this Airtable base to get started), we'll store a list of products, that will later be displayed in the app. The users will be able to like or unlike these products, and the liked products will be displayed in a separate app screen.
We need to include two special fields in our table:
A boolean field, that returns either True or False in the API response. In Airtable, this field can be created with a checkbox. In our example, it has the name Liked.
A text field, that converts the current state of the boolean field to text, with the values active or default. The way to implement this will depend on the backend tool you use. In Airtable, you can do it by creating a formula field, setting it to the following statement:
Apart from those two fields, you can create as many fields as you need for your data items.
Create the API requests in the Data Collections section
Once the table is created in the backend, it's time to go to Bravo Studio's Data Collections section and create the API requests. You'll need, at least, the following requests:
A PATCH request that changes the state of a component from default to active, by targeting the boolean field of our table.
Another PATCH request that, inversely, changes the state of a component from active to default.
Finally, a GET request that retrieves the data in our table. In case we're working with lists, we'll probably want to create both a list and a detail request.
For the PATCH requests, we'll need to edit the boolean field we previously created in the table. Therefore, in the JSON body of the request, we'll specify the value we want to set.
For the "default-to-active" PATCH request, we'll make the boolean value true:
{
  "fields": {
    "Liked": true
  }
}
On the other hand, for the "active-to-default" PATCH request, we'll make the boolean value false:
{
  "fields": {
    "Liked": false
  }
}
Keep in mind that this is a example using Airtable as the backend. For other tools, the JSON body structure you need to use in the PATCH requests will be different.
For the GET request, make sure you select the text item that returns either default or active, depending on the value of its associated boolean field. This is shown in the video below. We'll need to specify that name later in the Data Binding section.
Name of the data item cointaining the current state
Binding the API requests to the UI elements
Finally, it's time to bind the UI elements we created in the design file to the requests we just created.
First of all, we'll bind the GET request to the corresponding UI elements. In this case, as we want to display a list of products, we'll bind the container element to the data item containing the list, and then each individual UI element inside the container.
As you can see in the video below, we'll bind the group element containing the stateful component to the data item returning either "default" or "active". This sets the initial value of the stateful component, depending on the backend data.
Finally, we need to bind the remote actions associated to each of the states (default and active) to the corresponding PATCH request. 
For the default UI element, we'll bind the PATCH request that changes the component state from default to active, as this is the event that will happen in case a user presses a element with the default state. In our example, LIKED action.
On the other hand, for the active UI element, we'll bind the PATCH request that changes the component state from active to default. In our example, UNLIKED action.
Note that we'll specify Set State as the "On Success" action, in case the request is successful. In the text box, we need to write as a variable (with the ${} notation) the name of the data item we selected before in the API request, containing either default or active. In this example, it's called likedstate.
💾 Example files
Bravo Sample: Like Button
Figma
Map with markers
Multi-user setup with Xano
Last modified 10mo ago