Components: Nested Artboards, done right

Nested Artboards were our first crack at reusability: drop one artboard inside another, and you’re off to the races. For a while, that worked. As projects got bigger — from microinteractions to full production UIs — cracks started to show. 

Every artboard could be reused, which meant every artboard was dumped into your options. Exports bloated, file navigation turned chaotic, and debugging a teammate’s setup was harder than it needed to be. 

So we took a step back and asked: how should reusability actually work in Rive?

Why we made the change

The short answer: explicitness beats guesswork. 

From now on, artboards don’t automatically become reusable. To reuse and export an artboard, you flag it as a Component. That one step makes your intent explicit: what’s local stays local, and what’s reusable is clear in your assets panel.  

Nested Artboards worked, but they weren’t flexible enough for the workflows our community is building. As projects scale, especially across teams, designers and developers need predictable control over what gets reused and exported. Components solve that by making reusability an intentional choice.

This brings three big improvements:

1. Granular export control: Only flagged Components (plus your main artboard) get exported to runtime. Say goodbye to runtime bloat from artboards you didn’t mean to ship.

2. Cleaner organization: Big files stay manageable. Components live in a focused list of reusable elements, instead of every artboard piling up.

3. Future-ready: Components are the foundation to Libraries, where you’ll publish and reuse them across files and teams.

What’s different in your workflow

Flag what’s reusable

Before, every artboard was automatically nestable. Now, you explicitly flag artboards as Components when you want to reuse and export them. Regular artboards behave like drafts, so they’re useful for experimenting without bloating runtime. This small shift keeps projects intentional and lightweight. 

See it in color

Components are purple in the UI, regular artboards stay blue. A new toggle in the Inspector lets you turn Component status on or off anytime. Copies of Components in your file are called Instances. You’ll recognize them by their icons.

Migration built in

When opening older files, Rive auto-converts all artboards into Components so nothing breaks. Your exports are guaranteed to work exactly as before. You can prune if you want a leaner setup. 

Coming soon: More export options 

New behaviors, like automatic, force, or prevent, will give you fine-grained control over what makes it into runtime.

For existing users, these change should feel familiar and deliberate. You’ll recognize your old nested artboards by their new purple color and should get used to explicitly marking any new artboards you want to reuse. 

New users won’t need to relearn anything. Components are simply how Rive works now. It is worth noting that older tutorials or community files might mention Nested Artboards; when you see that term, just know it’s referring to what we now call Components. 

Technical details worth knowing

State Machines + Components: Components can contain their own State Machines. Nest them, and their logic stays self-contained. It’s perfect for modular UI elements like buttons or toggles.

Data Binding: Components work seamlessly with Data Binding. Marking an artboard as a Component makes it available to bind across files — critical for multi-file setups. Pair that with View Models and Enums, and you have the capacity for data-driven UI systems.

Runtime behavior: Components compile into the same lightweight .riv format. By flagging only what’s needed, you reduce file size and runtime overhead, especially in large projects.

Our thought process

When we reworked Nested Artboards, one of the biggest questions was: how do we talk about Components vs. Instances? 

If you’ve used Figma, this will feel familiar: the source is a Component; the copies in your file are Instances. In practice, though, most designers just call everything a Component. We didn’t want to bog the UI down with terminology. Instead, we’re conforming to familiar iconography to help differentiate: purple solid diamonds for Components, purple hollow diamonds for Instances. 

Surfacing every technical detail can add confusion. Our philosophy is to expose what’s useful, hide what’s distracting, and evolve as real-world workflows show us what’s essential.

That back-and-forth is part of how we design Rive: balancing clarity, power, and simplicity in equal measure.

Looking ahead

We’re announcing Components now, ahead of Libraries, for a reason: habits. By getting used to explicitly flagging what’s reusable today, you’ll be ready for Libraries tomorrow.

Libraries will build on Components with versioning, publishing, and shared design systems. Pair that with Data Binding and View Models, and you’ll have everything you need to create modular, data-driven UI that scales across teams and projects. 

For now: get used to purple. Components are how Rive works going forward.

Check out the docs or community if you’ve got questions, and keep an eye out for more updates as Libraries roll out.