Rive Blog
Build an interactive badge component with Data Binding
Rive Ambassador Leo Mazzei shares his personal workflow and tips for building reusable components in Rive.


Olá, olá! I'm Leo Mazzei, a Rive Ambassador and motion graphics specialist from Brazil, now based in Ontario, Canada. For the past year, I've been deep in the Rive Community helping designers and developers get up to speed with the newest features and overcome the mind-bending symptoms of what I like to call State Machine Paralysis.
In this walkthrough, we'll combine Rive features like the State Machine, Data Binding, Converters, View Models, Solos, and Enums to build a data-driven, customizable badge that can adapt to different inputs and be reused anywhere.
Let's get started.
The component we're creating
We'll build a badge that animates on hover and switches between bronze, silver, or gold versions. Each version can display a variety of sports icons, and it should be easy to add, remove, or modify them — the engineers in the room would call this "scalability."
You'll learn two different ways to use Enums:
As a State Machine transition condition
As a property connected to a Solo via Data Binding
Both methods have pros and cons; you'll see how they compare.
👉 Remix the file to follow along.
Set up your artboard
Create the artboard called badge and design your badge layout.
Keep a clean group structure. It'll make animation much simpler later.
Mark the artboard as a Component so it's reusable and exportable.
Lay the foundation for Data Binding
Before we add motion, we need data.
Data Binding starts with a View Model, which defines your data structure.
In the Data tab, click the + button and select View Model. Rename itbadgeVMfor clarity.
Next, give the View Model a property. Add a boolean property calledisHovering.
Then, in the Inspector, bind the View Model to your artboard. That connection allows the property to drive animations.
Add interactivity
Time to make it move!
Target your badge group with two listeners:
On cursor entry —> set
isHoveringtotrueOn cursor exit —> set
isHoveringtofalse
Create separate timelines for enter and exit animations. Then useisHoveringas the condition to drive the transitions between them inside the State Machine.
Need a refresher? Check out this guide to State Machines.
Create quality variants with Enums
Now let's scale this design with quality variants.
Next, we'll add bronze, silver, and gold versions with Enums. Enums let you create a clear list of named states instead of relying on arbitrary numbers or other property types.
Create an Enum from the + menu. Name it
qualityand add three options in the Inspector: bronze, silver, and gold. The Enum is just a list of names — it doesn't do anything on its own.Add an Enum property and name it
badgeQualityto your View Model and assign it thequalityEnum.
NowbadgeQualitycan drive states in your design.
With the logic in place, create timelines for each quality variant, keyframing the badge color to match.
Then, create a new State Machine layer and connect the quality timelines to Any State, using the Enum property badgeQuality as the condition.
Add icon variants with Enums and Solos
With the badge logic done, let's make it dynamic. Now for the fun part: icons.
Import your icons and add them to the artboard. Wrap them in a Solo and give each one a unique name. Because of your clean structure, adding icons won't break existing animations.
Tip: Set the icons to a different blend mode so badge colors transfer automatically. This will save you from adding extra keyframes.
Now you'll create a new Enum to control the icons, just like you did for the quality variants:
Create an Enum named
iconand add options matching your icon names in your Solo group.Add an Enum property called
badgeIconto your View Model and assign it theiconEnum.
Instead of building more State Machine layers, we'll use Data Binding by binding this Enum directly to the Solo's Active property. Now you can add new icons effortlessly without crowding your state machine layers.
To do that:
Expose the icon names by selecting each group, right-clicking, and then toggling “Export name.” This makes the layer names accessible to the data bindings.
Create a Convert to String converter by clicking the + menu > Converters > String > Convert to String.
Bind the Solo's
Activeproperty tobadgeIconand attach the converter to the bind right below.
Note: If the concept of converters still gives you State Machine Paralysis, I highly recommend thinking about them as cable adaptors, as Mayte says in this must-read blog post. Save it for later, though. Let's finish what we've started!
Make the component reusable
A View Model defines your component's properties; a View Model Instance is a live version of it filled with values.
This separation is powerful. It unlocks the ability to create endless variations of a single component — just by plugging in different instances, each with its own unique data and configuration.
Select your View Model, head to the Inspector, and use the options menu to add three new instances.
Since the new instances' count starts at one, I personally like to keep the default ‘Instance’ with arbitrary values that I can tweak however I want without affecting the actual instances.
Now, select each instance individually and assign unique values to its badgeIcon and badgeQuality properties. Just like that, you’ve created three distinct permutations, all selectable directly from the Inspector.
Connect component instances
Now that we have three separate view model instances, we can bind them to different Component instances.
Create a new artboard called display and use the Component tool to bring three copies of the Badge Component. If you don't see the option to import it, you need to go back and mark it as a Component.
Component instances are like empty vessels; a View Model Instance is what gives them life.
Now, let's build a controller to manage our badge variations.
Create a new View Model — call it displayVM — and connect it to your main display artboard.
Here's a powerful technique: you can nest View Models as properties. Inside displayVM, click the + button to add three new View Model properties of type badgeVM — and yes, that's the view model we've been working on all this time. By nesting a view model inside another, the editor lets you connect it to component instances that may exist in your board.
To finish, select each of the newly added properties and use the Inspector to connect them to one of the View Model Instances we created.
With the setup complete, it's time for the final connection: select each of the three component instances on your artboard and use the Inspector to connect them to a different badgeVM property.
You now have three independent, data-driven badges all powered by one reusable setup.
That's a wrap
You've built a scalable badge component that reacts to user input and adapts to Rive data. Even better? It's ready for implementation.
Once this workflow clicks, it becomes second nature — and you'll no longer have State Machine Paralysis.
If you made it this far, congratulations. You've officially leveled up your Rive muscle memory.
Ready to explore? Remix the file or build your own version from scratch using these techniques.
Thanks for reading! Come say hi in the Rive Community. I'd love to see what you make.
Dive deeper into the State Machine and Data Binding
Olá, olá! I'm Leo Mazzei, a Rive Ambassador and motion graphics specialist from Brazil, now based in Ontario, Canada. For the past year, I've been deep in the Rive Community helping designers and developers get up to speed with the newest features and overcome the mind-bending symptoms of what I like to call State Machine Paralysis.
In this walkthrough, we'll combine Rive features like the State Machine, Data Binding, Converters, View Models, Solos, and Enums to build a data-driven, customizable badge that can adapt to different inputs and be reused anywhere.
Let's get started.
The component we're creating
We'll build a badge that animates on hover and switches between bronze, silver, or gold versions. Each version can display a variety of sports icons, and it should be easy to add, remove, or modify them — the engineers in the room would call this "scalability."
You'll learn two different ways to use Enums:
As a State Machine transition condition
As a property connected to a Solo via Data Binding
Both methods have pros and cons; you'll see how they compare.
👉 Remix the file to follow along.
Set up your artboard
Create the artboard called badge and design your badge layout.
Keep a clean group structure. It'll make animation much simpler later.
Mark the artboard as a Component so it's reusable and exportable.
Lay the foundation for Data Binding
Before we add motion, we need data.
Data Binding starts with a View Model, which defines your data structure.
In the Data tab, click the + button and select View Model. Rename itbadgeVMfor clarity.
Next, give the View Model a property. Add a boolean property calledisHovering.
Then, in the Inspector, bind the View Model to your artboard. That connection allows the property to drive animations.
Add interactivity
Time to make it move!
Target your badge group with two listeners:
On cursor entry —> set
isHoveringtotrueOn cursor exit —> set
isHoveringtofalse
Create separate timelines for enter and exit animations. Then useisHoveringas the condition to drive the transitions between them inside the State Machine.
Need a refresher? Check out this guide to State Machines.
Create quality variants with Enums
Now let's scale this design with quality variants.
Next, we'll add bronze, silver, and gold versions with Enums. Enums let you create a clear list of named states instead of relying on arbitrary numbers or other property types.
Create an Enum from the + menu. Name it
qualityand add three options in the Inspector: bronze, silver, and gold. The Enum is just a list of names — it doesn't do anything on its own.Add an Enum property and name it
badgeQualityto your View Model and assign it thequalityEnum.
NowbadgeQualitycan drive states in your design.
With the logic in place, create timelines for each quality variant, keyframing the badge color to match.
Then, create a new State Machine layer and connect the quality timelines to Any State, using the Enum property badgeQuality as the condition.
Add icon variants with Enums and Solos
With the badge logic done, let's make it dynamic. Now for the fun part: icons.
Import your icons and add them to the artboard. Wrap them in a Solo and give each one a unique name. Because of your clean structure, adding icons won't break existing animations.
Tip: Set the icons to a different blend mode so badge colors transfer automatically. This will save you from adding extra keyframes.
Now you'll create a new Enum to control the icons, just like you did for the quality variants:
Create an Enum named
iconand add options matching your icon names in your Solo group.Add an Enum property called
badgeIconto your View Model and assign it theiconEnum.
Instead of building more State Machine layers, we'll use Data Binding by binding this Enum directly to the Solo's Active property. Now you can add new icons effortlessly without crowding your state machine layers.
To do that:
Expose the icon names by selecting each group, right-clicking, and then toggling “Export name.” This makes the layer names accessible to the data bindings.
Create a Convert to String converter by clicking the + menu > Converters > String > Convert to String.
Bind the Solo's
Activeproperty tobadgeIconand attach the converter to the bind right below.
Note: If the concept of converters still gives you State Machine Paralysis, I highly recommend thinking about them as cable adaptors, as Mayte says in this must-read blog post. Save it for later, though. Let's finish what we've started!
Make the component reusable
A View Model defines your component's properties; a View Model Instance is a live version of it filled with values.
This separation is powerful. It unlocks the ability to create endless variations of a single component — just by plugging in different instances, each with its own unique data and configuration.
Select your View Model, head to the Inspector, and use the options menu to add three new instances.
Since the new instances' count starts at one, I personally like to keep the default ‘Instance’ with arbitrary values that I can tweak however I want without affecting the actual instances.
Now, select each instance individually and assign unique values to its badgeIcon and badgeQuality properties. Just like that, you’ve created three distinct permutations, all selectable directly from the Inspector.
Connect component instances
Now that we have three separate view model instances, we can bind them to different Component instances.
Create a new artboard called display and use the Component tool to bring three copies of the Badge Component. If you don't see the option to import it, you need to go back and mark it as a Component.
Component instances are like empty vessels; a View Model Instance is what gives them life.
Now, let's build a controller to manage our badge variations.
Create a new View Model — call it displayVM — and connect it to your main display artboard.
Here's a powerful technique: you can nest View Models as properties. Inside displayVM, click the + button to add three new View Model properties of type badgeVM — and yes, that's the view model we've been working on all this time. By nesting a view model inside another, the editor lets you connect it to component instances that may exist in your board.
To finish, select each of the newly added properties and use the Inspector to connect them to one of the View Model Instances we created.
With the setup complete, it's time for the final connection: select each of the three component instances on your artboard and use the Inspector to connect them to a different badgeVM property.
You now have three independent, data-driven badges all powered by one reusable setup.
That's a wrap
You've built a scalable badge component that reacts to user input and adapts to Rive data. Even better? It's ready for implementation.
Once this workflow clicks, it becomes second nature — and you'll no longer have State Machine Paralysis.
If you made it this far, congratulations. You've officially leveled up your Rive muscle memory.
Ready to explore? Remix the file or build your own version from scratch using these techniques.
Thanks for reading! Come say hi in the Rive Community. I'd love to see what you make.
Dive deeper into the State Machine and Data Binding
Olá, olá! I'm Leo Mazzei, a Rive Ambassador and motion graphics specialist from Brazil, now based in Ontario, Canada. For the past year, I've been deep in the Rive Community helping designers and developers get up to speed with the newest features and overcome the mind-bending symptoms of what I like to call State Machine Paralysis.
In this walkthrough, we'll combine Rive features like the State Machine, Data Binding, Converters, View Models, Solos, and Enums to build a data-driven, customizable badge that can adapt to different inputs and be reused anywhere.
Let's get started.
The component we're creating
We'll build a badge that animates on hover and switches between bronze, silver, or gold versions. Each version can display a variety of sports icons, and it should be easy to add, remove, or modify them — the engineers in the room would call this "scalability."
You'll learn two different ways to use Enums:
As a State Machine transition condition
As a property connected to a Solo via Data Binding
Both methods have pros and cons; you'll see how they compare.
👉 Remix the file to follow along.
Set up your artboard
Create the artboard called badge and design your badge layout.
Keep a clean group structure. It'll make animation much simpler later.
Mark the artboard as a Component so it's reusable and exportable.
Lay the foundation for Data Binding
Before we add motion, we need data.
Data Binding starts with a View Model, which defines your data structure.
In the Data tab, click the + button and select View Model. Rename itbadgeVMfor clarity.
Next, give the View Model a property. Add a boolean property calledisHovering.
Then, in the Inspector, bind the View Model to your artboard. That connection allows the property to drive animations.
Add interactivity
Time to make it move!
Target your badge group with two listeners:
On cursor entry —> set
isHoveringtotrueOn cursor exit —> set
isHoveringtofalse
Create separate timelines for enter and exit animations. Then useisHoveringas the condition to drive the transitions between them inside the State Machine.
Need a refresher? Check out this guide to State Machines.
Create quality variants with Enums
Now let's scale this design with quality variants.
Next, we'll add bronze, silver, and gold versions with Enums. Enums let you create a clear list of named states instead of relying on arbitrary numbers or other property types.
Create an Enum from the + menu. Name it
qualityand add three options in the Inspector: bronze, silver, and gold. The Enum is just a list of names — it doesn't do anything on its own.Add an Enum property and name it
badgeQualityto your View Model and assign it thequalityEnum.
NowbadgeQualitycan drive states in your design.
With the logic in place, create timelines for each quality variant, keyframing the badge color to match.
Then, create a new State Machine layer and connect the quality timelines to Any State, using the Enum property badgeQuality as the condition.
Add icon variants with Enums and Solos
With the badge logic done, let's make it dynamic. Now for the fun part: icons.
Import your icons and add them to the artboard. Wrap them in a Solo and give each one a unique name. Because of your clean structure, adding icons won't break existing animations.
Tip: Set the icons to a different blend mode so badge colors transfer automatically. This will save you from adding extra keyframes.
Now you'll create a new Enum to control the icons, just like you did for the quality variants:
Create an Enum named
iconand add options matching your icon names in your Solo group.Add an Enum property called
badgeIconto your View Model and assign it theiconEnum.
Instead of building more State Machine layers, we'll use Data Binding by binding this Enum directly to the Solo's Active property. Now you can add new icons effortlessly without crowding your state machine layers.
To do that:
Expose the icon names by selecting each group, right-clicking, and then toggling “Export name.” This makes the layer names accessible to the data bindings.
Create a Convert to String converter by clicking the + menu > Converters > String > Convert to String.
Bind the Solo's
Activeproperty tobadgeIconand attach the converter to the bind right below.
Note: If the concept of converters still gives you State Machine Paralysis, I highly recommend thinking about them as cable adaptors, as Mayte says in this must-read blog post. Save it for later, though. Let's finish what we've started!
Make the component reusable
A View Model defines your component's properties; a View Model Instance is a live version of it filled with values.
This separation is powerful. It unlocks the ability to create endless variations of a single component — just by plugging in different instances, each with its own unique data and configuration.
Select your View Model, head to the Inspector, and use the options menu to add three new instances.
Since the new instances' count starts at one, I personally like to keep the default ‘Instance’ with arbitrary values that I can tweak however I want without affecting the actual instances.
Now, select each instance individually and assign unique values to its badgeIcon and badgeQuality properties. Just like that, you’ve created three distinct permutations, all selectable directly from the Inspector.
Connect component instances
Now that we have three separate view model instances, we can bind them to different Component instances.
Create a new artboard called display and use the Component tool to bring three copies of the Badge Component. If you don't see the option to import it, you need to go back and mark it as a Component.
Component instances are like empty vessels; a View Model Instance is what gives them life.
Now, let's build a controller to manage our badge variations.
Create a new View Model — call it displayVM — and connect it to your main display artboard.
Here's a powerful technique: you can nest View Models as properties. Inside displayVM, click the + button to add three new View Model properties of type badgeVM — and yes, that's the view model we've been working on all this time. By nesting a view model inside another, the editor lets you connect it to component instances that may exist in your board.
To finish, select each of the newly added properties and use the Inspector to connect them to one of the View Model Instances we created.
With the setup complete, it's time for the final connection: select each of the three component instances on your artboard and use the Inspector to connect them to a different badgeVM property.
You now have three independent, data-driven badges all powered by one reusable setup.
That's a wrap
You've built a scalable badge component that reacts to user input and adapts to Rive data. Even better? It's ready for implementation.
Once this workflow clicks, it becomes second nature — and you'll no longer have State Machine Paralysis.
If you made it this far, congratulations. You've officially leveled up your Rive muscle memory.
Ready to explore? Remix the file or build your own version from scratch using these techniques.
Thanks for reading! Come say hi in the Rive Community. I'd love to see what you make.
Dive deeper into the State Machine and Data Binding
Join our newsletter
Get all the latest Rive news delivered to your inbox.