FieldNotify fields on Widgets and MVVM

In Unreal with the MVVM plugin, a potentially unintended side effect/feature/bug is that a Widget can mark internal variables as field notify and leverage the MVVM plugin and editor tooling to bind widget fields to its own field notifiable variables. Ostensibly treating the widget itself as a view model. This doesn’t seem truly intentional since the editor prevents adding bindings until you add a view model - though you can work around this by adding a view model and removing it.

Is this an intended feature of the field notify system or simply a side effect of the MVVM toolchain not particularly being opinionated on where field notify bind sources come from? It’s not documented but it actually is a fairly useful feature to allow more declarative widget building and separation of presentation logic vs. UI logic.

But curious if this is unintentionally supported and should not be relied on.

Steps to Reproduce

  1. Create a new user widget.
  2. Add a widget variable and mark it as field notify.
  3. Add a fake view model to unlock the widget MVVM binding editor.
  4. Add a binding from an element of the widget (say, a text field) to the widget variable.
  5. Remove the fake view model.

Hi Kevin,

That workflow is largely a side-effect of the implementation of FieldNotify properties, though there aren’t any specific concerns about working that way if you’re fine with fighting the editor UI a bit to make the bindings window behave. Our approach in that case would be to make a ViewModel for each widget class with it’s creation method set to Create Instance (since it results in the same 1:1 pairing of VM to Widget), but if you prefer to skip creating an extra class and binding to properties directly then it should be fine. I wouldn’t promise that the workflow will be supported forever since we aren’t really testing that scenario, but beyond that I wouldn’t expect it to cause any problems.

Best,

Cody

That makes sense. I guess creating a VM with is more idiomatic, at the cost of having another file to deal with. Thanks for the clarification!