Best practice for global singleton ViewMode?

[eefan000]

No description provided.

[grashaar]

Could you please give out more information on the usecase?

[eefan000]

Could you please give out more information on the usecase?

https://dev.epicgames.com/documentation/en-us/unreal-engine/umg-viewmodel#globalviewmodelcollection

[eefan000]

In the game, there are many global ViewModels, such as account data, current level data, tasks, and so on.

For these global ViewModels, it would be much more convenient if they could be directly referenced when binding data in the UI, without the need to manually install the ViewModel through code.

[grashaar]

Truthfully the current implementation only supports binding through setting up components on GameObject beforehand. Binding through code has not been supported very well; many autormated mechanism is currently missing. I'm afraid it might take a while before I can work on these missing pieces.

[eefan000]

Can we refer to UE5 MVVM and add a global binding context option in the binding context?
Register a global VM in the code?
It doesn't seem like a big change, I'll try making it myself later

[grashaar]

Feel free to fork this repo and experiment however you please. Btw, if I might have a word of caution, a global strategy should be designed carefully and fully decoupled from the core functionality. Especially singletons should only be an extension to the core.

[eefan000]

I have a preliminary implementation now, and it looks like this when used

SVN difference.txt

@grashaar Do you have any evaluation of this simple implementation

[grashaar]

I really don't like the idea of coupling MonoBindingContext with detailed implementation on how to get the ObservableObject reference. The global object should be injected into MonoBindingContext via a different component.

[eefan000]

I really don't like the idea of coupling MonoBindingContext with detailed implementation on how to get the ObservableObject reference. The global object should be injected into MonoBindingContext via a different component.

The main purpose is to reduce the number of operational steps. If it is an independent component, it is necessary to synchronize some settings to MonoBindContext to ensure that MonoBinder can display relevant information normally in the future

I expect that in most cases in my project, it will be GlobalObject, which will result in the need for many additional GlobalObject components

[grashaar]

I think what is missing from the current MonoBindingContext is the ability to provide any type information for the binders. Type information should be decoupled from runtime instances of ObservableObject.

[eefan000]

Indeed, I think it's even possible to consider selecting the target VM type and target property path directly on each attribute of the binder.

The multiple VM instances required by the binder are installed at runtime by external features such as MonoBindContext, Enhanced GridBinding, or GlobalObject Components

[grashaar]

Then we need a powerful editor toolset to govern the target types and its property paths so we can notify the user if any type is missing or some property paths no longer exist. Because the target types will be scattered everywhere across the View prefab.

[eefan000]

Consider directly based on Odin, which makes it easier to scale and reduces workload.

I don't think anyone wouldn't need Odin🤔

[grashaar]

Odin is a paid software, it can't be a dependency for an open source library such as this. On the other hand, I don't think Odin can help much instead of providing premade utitlities to work with types.