Rive data binding & View Model Instances

Data binding is how Rive connects design to code: designers declare typed properties in the editor, and your app reads and writes them at runtime through a View Model Instance (VMI). Here's how the pieces fit — and how to see them live inside any .riv file.

Inspect your file's data binding live →

What is a View Model?

A View Model is the schema. In the Rive editor, a designer attaches one to an artboard and declares its properties: a speed number, an isMuted boolean, a title string, a theme enum. The View Model defines what exists and its types — not the values. Think of it as the typed contract between the design and your code.

What is a View Model Instance (VMI)?

A View Model Instance is a live copy of that contract, holding actual values at runtime. When your app loads the .riv (with auto-binding or manual binding), the runtime hands you a VMI object: read speed, set title, fire a trigger — and every element bound to those properties updates instantly, including state machine transitions that condition on them. One View Model can have many instances, each with its own values.

Property types in Rive data binding

Type	Holds	Typical use
`boolean`	true / false	toggles, visibility, mute state
`number`	floating-point value	progress, speed, score
`string`	text	labels, names, dynamic copy
`color`	32-bit ARGB color	theming, brand colors
`enum`	one of a fixed set	variants, themes, sizes
`trigger`	one-shot event	fire a transition or effect
`view model`	a nested instance	structured data (e.g. a user card)
`list`	ordered instances	repeating items (rows, avatars)

Rive keeps adding types — newer runtimes also expose image and artboard properties — but the eight above are the core set you'll meet in most files today.

Data binding vs. state machine inputs

Before data binding, runtime control went through state machine inputs (SMI): SMIBool, SMINumber and SMITrigger attached to a specific state machine. Inputs still work and are great for simple control. Data binding is the richer model: typed properties on a view model, two-way binding to any element property, nested structures and lists — closer to how UI frameworks think. New projects increasingly expose their runtime API through view models, with inputs reserved for simple flags.

See it live: inspect any .riv file's data binding

Open rive.best and drop in your .riv file.
The inspector auto-binds the default View Model Instance and lists every property by type.
Change values and fire triggers — the canvas reacts in real time.
Copy a ready-made code stub for each property for @rive-app/canvas, react-canvas or react-native.

It's the fastest way to answer "what does this file expose?" — whether the .riv came from your own editor, a teammate, or a marketplace.

Frequently asked questions

What is the difference between a View Model and a View Model Instance?

A View Model is the blueprint: it declares which typed properties exist (booleans, numbers, strings, colors, enums, triggers, nested view models, lists). A View Model Instance (VMI) is a live copy of that blueprint holding actual values at runtime — the object your code reads and writes, and the one your artboard and state machine bind to.

How do I see which view model properties a .riv file exposes?

Drop the .riv into the rive.best inspector. It auto-binds the default View Model Instance and lists every data-binding property grouped by type, with its current value. You can pin properties to a watch list and copy a ready-made code snippet for each one.

Can I change View Model Instance values at runtime?

Yes — that is the point of data binding. Set a number, string, color, enum or boolean, or fire a trigger, and every bound element in the artboard updates immediately. The rive.best inspector lets you do this from the UI to test behavior before writing any integration code.

Open the View Model Instance inspector →