Feedback UI Toolkit Custom control best practices. Using custom control as UI manager as opposed to monobehav

The Unity documentation suggest that custom control should be reserved for atomic object reusable objects. However I have found that using custom control for UI manager might be viable and wanted to hear feedback. Let's say I have a QuickMenuManager : VisualElement, I have found that I could add this element to a VisualTree QuickMenu asset template I create and therefore is beneficial for encapsulation. I can then add instance of this template in my application and the code is self contained. The alternative is to add a gameObject at the root level of the UIDocument and access the VisualElement using the Q (Query) API. As you can see the QuickMenu is no longer contained in the VisualTree asset. Why is the documentation so harsh against this kind of approach?

Unity 2023.2 Documentation:
A good custom control is abstract, self-contained, and recurring.
A Slide Toggle is a good example of a custom control:
It’s abstract. You use it to switch between one setting and another.
It’s self-contained. You give it a label and an initial value. A Slide Toggle triggers an event when its state changes.
It’s recurring. You can use it in multiple places in an application.

The menu bar of your application isn’t a good example of a custom control:
It’s not abstract. It’s specific to your application.
It’s not self-contained. It probably has dependencies on other parts of your application.
It’s not recurring. There is probably only one menu in your application.
After you have created a custom control, you can style it with USS and add logic to handle events in C#.

https://docs.unity3d.com/2023.2/Documentation/Manual/UIE-create-custom-controls.html

 

I think the docs are trying reinforce the separation between the visuals and the data. Ergo, UI is just UI. It just looks pretty and displays relevant information.

And then your monobehaviours manage all the data and runtime stuff, as they're a part of your general Unity life cycle.

Though to be honest I make custom controls for one-off purposes all the time, as it's often easier/quicker/more clear. That's my style though. I can see the reasoning for keeping a strict divide here and were I to work on a very UI heavy project I would probably take this approach.

 

Is runtime data binding what I am looking for? So the idea with runtime data binding would be to setup my QuickMenuManager as a MonoBehaviour and let it reference a QuickMenuDataSource scriptableobject. The QuickMenuDataSource scriptable object is then assigned to the QuickMenu corresponding VisualElement in the UI Builder? Seems like this beats accessing VisualElement from the document via string queries. Am I missing anything?

What advantage does runtime data binding offer over custom control? It seems like just extra boilerplate.

Discussion about runtime data binding:
https://forum.unity.com/threads/int...ngs-api-in-unity-2023-2.1454221/#post-9223635

 

Thanks! What would be the advantage of using runtime data binding over a one off custom visual element as a way to script your interface then? Seems like the later is more self contained anyway.

The only thing I see is that the runtime data binding approach lets you customize your UI without opening the UI builder. But I'm going to do that anyway when I change my UI.

 

Why would you try to link data with UI since a custom VisualElement can listen to any game event (via a singleton event container, or via ScriptableObject event container passed as reference thanks to the new object attribute for visual element) and modify the subhierarchy it wants upon hearing the callback?

Maybe it is precisely the listening to callback and updating UI boilerplate that runtime databinding is trying to get rid of. But I am wondering if it is worth it to have to maintain the UI Manager gameObject + MonoBehaviour and UI Visual Element independently for that reason?

As you point out, what would be a use case for a custom visual element and runtime databinding working together?

Sorry for the insistence. It is just that coming from Unity old UI system, letting the UI submodule handle itself was very common. Now that I know that some people use one off custom control visual element as pseudo MonoBehaviour (thanks to yours and spiney199 replies) to replicate this behaviour, then this adds even more confusion since the top down approach isn't enforced as much as I thought.

 

Honestly just do what works for you. Don't get too caught up overthinking it.

If your first approach doesn't work out, change your approach.

 

When you explain it like that it is starting to make sense. Thank you!