Skip to content

Conversation

@mfazekas
Copy link
Collaborator

Summary

Fixes #124 - useViewModelInstance hook now correctly handles the name parameter:

  • name consistently means ViewModel instance name (not ViewModel class name) for both RiveFile and ViewModel sources
  • New artboardName param for RiveFile source to specify which artboard's ViewModel to use
  • TypeScript overloads enforce param availability by source type (e.g., artboardName only available for RiveFile)

Test plan

  • Unit tests pass (yarn test)
  • TypeScript compiles (yarn typecheck)
  • Lint passes (yarn lint)
  • Harness tests on device

@mfazekas mfazekas force-pushed the fix/vmi-name-param branch 6 times, most recently from b8c39a3 to a7e68aa Compare January 21, 2026 05:17
@mfazekas mfazekas changed the base branch from main to test/hook-harness January 21, 2026 09:16
@mfazekas mfazekas marked this pull request as ready for review January 21, 2026 09:18
@mfazekas mfazekas requested a review from HayesGordon January 21, 2026 09:18
Base automatically changed from test/hook-harness to main January 21, 2026 10:28
The name param now consistently means ViewModel instance name for both
RiveFile and ViewModel sources. Added artboardName param for RiveFile
to specify which artboard's ViewModel to use. TypeScript overloads now
enforce param availability by source type.

Returns specific error messages when explicit params (artboardName, name)
don't match - only throws if required: true.
@mfazekas mfazekas changed the title fix(hooks): clarify useViewModelInstance name param semantics feat: useViewModelInstance use name and artboardName when getting vmi from a file Jan 21, 2026
@mfazekas mfazekas enabled auto-merge (squash) January 21, 2026 10:45
Copy link
Contributor

@HayesGordon HayesGordon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! I left one comment, but this is something we will address in the ideal API when we adopt the new iOS and Android runtimes.

* The name of the artboard to get the ViewModel from.
* If not provided, uses the default artboard.
*/
artboardName?: string;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this, but I'm worried that we now have many ways to do the same thing. You could get the correct vmi by doing:

const viewModel = riveFile?.viewModelByName('My View Model');
const namedInstance = useViewModelInstance(viewModel, { name: 'My Instance' });

I'm worried that if we expose this convenience, we bury this usage. Which is important when you're working with lists.

But I see the convenience of this. Ideally, with the future API where you will have the Artboard and State Machine configured before creating the view, this additional parameter won't be needed as the artboard will already be known by then.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one option is extending the options to useViewModelInstance(file, { options })

so there could be artboardName, viewModelName and instanceName.

In this PR it's arboardName and name (instead of instanceName). But instanceName would be better - more explicit.

const viewModel = riveFile?.viewModelByName('My View Model');
const namedInstance = useViewModelInstance(viewModel, { name: 'My Instance' });

Yep that's works too. The only thing is that since const viewModel = riveFile?.viewModelByName('My View Model'); is not a hook there is a decision the user has to make if he wants to memoize it or not. Probably doesn't matter as viewModelByName is very fast I'd assume.

This would be the equivalent:

const namedInstance = useViewModelInstance(viewModel, { modelName: 'My View Model', instanceName: 'My Instance' });

@mfazekas mfazekas merged commit 5615654 into main Jan 21, 2026
7 of 8 checks passed
@mfazekas mfazekas deleted the fix/vmi-name-param branch January 21, 2026 11:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants