[Feature Request] Expose ViewModel Change event

[ncthbrt]

Submission checklist

• I have confirmed the issue is present in the latest version of the Rive Unity package
• I have searched the documentation and forums and could not find an answer
• I have searched existing issues and this is not a duplicate

Description

To reduce errors, our project has created strongly typed wrappers around the Rive view models in the game. However a common issue we face is that game logic can bind a new instance of a view model, leading to stale references to view models.

This isn't generally a problem when simply retrieving or setting values as our wrappers reobtain the root view model instances from the state machine each time, however we haven't found a good solution to ensuring that events such as OnTrigger and OnChange are always subscribed to the latest version of a property.

Previous working version

No response

Reproduction steps / code

No response

Upload your reproduction files / stack trace

No response

Source .riv / .rev file

No response

Screenshots / video

No response

Unity Editor log file

No response

Rive Unity package version

v0.4.5

Unity version

v6000.5.0f1

Target platform

macOS

Editor OS & version

macOS Tahoe 26.5.2

Additional context

No response

[damzobridge]

Thanks for opening an issue for this! Could you share more about how or when you'd run into this scenario? Even if it's pseudo-code. Mostly asking because we don't expose a ViewModel change event in any of our runtimes, so I'm trying to make sure I fully understand the context.

Initially, I thought it might be related to this best practice where we recommend having a wrapper script that the rest of your C# code interacts with, instead of them directly working with rive classes, so you can update things in one place.

However, the "ensuring that events such as OnTrigger and OnChange are always subscribed" situation seems strange, because your code fetches the root view model instances from the state machine each time, so I assume you're also fetching the trigger properties after that?

[ncthbrt]

This is specifically for nested view models.

For example you might have the following hierarchy:

• GameViewModel
  • SettingsMenuViewModel
    • SettingTabViewModel
      • OnSaveTrigger

Now imagine you had a feature that allowed you to reset the settings. One way to do this would be to bind a new instance of the SettingsMenuViewModel inside Rive. However on the Unity side, a script listening for the OnSaveTrigger would not know that it needed to resubscribe to the new view model instance unless some bespoke trigger was fired to inform the Unity side of things that the view model has been rebound. This means that it is quite difficult to build abstractions around view model unless you force developers into a convention driven ViewModel design to work around this problem.

A simpler example is a theme chooser which swaps out the current theme contained within a ViewModel inside the Rive side of things. Without a ViewModel change listener, the host application would not know that the theme had changed, unless again, as above, some per ViewModel bespoke behaviour is created