Setting up the backend of Stateful component (like button)

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.

👉 The Tags

Remember to add this tags in the design file to implement the toggle component.

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:active][action:remote]
[state:default][action:remote]

These components must be surrounded by a group

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

https://www.figma.com/community/file/1052981944574630146/Bravo-Sample%3A-Like-Buttonwww.figma.com

See the following article to implement this functionality with Xano:

Multi-user setup with Xano | Bravo Studio Help Centerdocs.bravostudio.app