u/Jeff_at_Rive

Data binding keys let you link a timeline key to a view model property instead of a fixed value. Your animation still interpolates on the timeline, but the target value comes from your view model at runtime.

In animate mode, key a property on your timeline. Right-click the key, choose Data Bind, and pick a view model property. You can mix fixed keys and bound keys on the same timeline — e.g. key a value at 0 on frame 0, then bind a second key later in the timeline to a dynamic property.

Three patterns from the video:

Basic motion: Set up number properties (minX, maxX) in your view model. Key X position at the start and end of a timeline and bind each key to the corresponding property. The animation interpolates between those runtime values.

Bar chart: Use a layout with height set to fixed percentage. Add a number property to your view model. Key height at 0 on frame 0, add a second key later and data-bind it to your value property. The bar animates from 0 to whatever the view model provides.

Button colors: Create a global view model with color properties for your brand colors. In separate idle and hover timelines, key the background fill and bind each to the matching global color. Wire them up in a state machine with a boolean for hover state, add interpolation, and the color transitions stay in sync with whatever values you pass in at runtime.

Global view models in Rive have properties that are available to every artboard in your file automatically. No need to attach them to specific artboards. Any artboard, any component, any nested artboard can data bind to them with no additional setup.

What you can use them for:

Design systems. Create a global view model for your brand style tokens like colors, fonts, spacing and sizing values. Every component in the file can bind to those properties. Change the brand primary color once and it updates everywhere.

Components that mix global and local properties. A button component might use global colors (brand primary, hover) alongside local properties like the label text and hover boolean. Both can coexist on the same artboard.

Data-bound keys in timelines and state machines. You can key a property in a timeline and bind that key's value to a global property. So your idle state background binds to brandPrimary, your hover state background binds to brandHover, and the colors update globally across all instances.

Shared runtime data. If you're building something like a sports broadcast, a single global view model can hold the score, team names, and team crests. Every component in the file (score bug, lower third, full-screen graphic) reads from the same source, so updates reflect everywhere at once.

Libraries. Global view models can be published as a library and shared across multiple files in a project, not just within a single file.

Quick tips video on using position absolute in Rive — covers overlays, sticky elements, reusable effect components, and a zero-by-zero layout trick for flyout menus that stay anchored correctly as the artboard resizes.

Rive's listener action scripts let you run custom logic when a listener fires in a state machine. One practical use case: distinguishing a double click from a single click, which is tricky to do with standard listeners alone.

Here's how the double click detector works:

The script uses three properties in its type definition: a threshold number (default 0.3 seconds), a clicked trigger, and a doubleClicked trigger pulled from the view model, plus a lastClickTime number initialized to -1.

In init, it grabs the view model and resolves both triggers by name.

In performAction, it checks that the incoming action is a pointer event, then captures the current time. It compares lastClickTime against the threshold:

• If lastClickTime >= 0 and time elapsed ≤ threshold → fires doubleClicked, resets lastClickTime to -1
• Otherwise → fires clicked, sets lastClickTime to now

Because threshold is exposed as a script input, you can override it per-listener without touching the script itself. In the demo it's set to 0.3s by default, adjustable to 0.5s or whatever feels right for your use case.

To wire it up: select your listener target shape, add a listener, set the event to Click, choose the listener action script type, and pick your script. The threshold input appears inline. Then in the state machine, use the Any State node with clicked and doubleClicked trigger conditions to drive transitions to whichever animations you want.

The video shows this applied to a bubble animation — single click triggers a grow-and-shrink, double click triggers a pop.

Stateful Components are a new way to reuse components in Rive without wiring up a separate view model instance for each one.

Here's how they work: you build a component (say, a button) and attach a view model with whatever properties you want to expose — label text, background color, text color, etc. When you make it a component, you'll see a new Properties section in the inspector. Click + to choose which view model properties to expose, and mark each one as either input (you can set the value per instance) or output (the value can be read by a parent).

Once you nest that component somewhere else and flip it to stateful, those exposed properties show up directly in the inspector. Each instance can have its own values — no nested view model required. Copy the component 3 times, give each one a different label and color, done.

Nesting goes deeper too. A card component with its own view model can contain a stateful button, and you can bubble the button's properties up through the card's view model so the parent can override them as well.

Output properties work the other way: a slider component can expose its current value as an output, and a parent artboard can data bind to that value to read it in real time.

One more thing: input properties can be keyed on timelines. So you can animate a per-instance color override across a loop without touching the original component.

Relative binding in Rive lets you bind properties by name rather than by a fixed path. That means two completely different artboards — from two different files, with different view model names — can share the same data at runtime, as long as the property names match.

This video covers two practical uses of that:

1. Swapping a single artboard component at runtime. You wrap your artboard in a parent file, bind the nested artboard to an "artboard" property using bind relative, then swap in a different .rive file at runtime. The replacement artboard picks up all the same data automatically — even if the source file has a differently named view model, the properties still resolve correctly.

2. Swapping individual components in a multi-component dashboard. The example uses a world population dashboard with 7 continents, each with its own nested view model instance (color, name, population, percent). The dashboard has slots for different chart types — donut, bar, table. At runtime you can replace any slot with a new component from an external file. As long as the component's view model uses the same property names, the data maps over without any rewiring.

The key rule: property names must match. View model names and nesting order don't matter.

Useful if you're building things like:

• Theming systems where the design can be swapped without touching the data layer
• Dashboards with interchangeable visualizations
• Library components that work across multiple host files