[UI Toolkit] Roadmap "Generic UI data binding"

Unity Engine
,
1

The UI Toolkit has the UI data binding in progress for some time.
Nothing has been shown yet as far as I’m aware.

What will the ‘improved workflow’ be for data binding?
Will there be a two-way data binding?

2

Hey @MaskedMouse !

Indeed, we’ve been working on a generic data binding solution for UI Toolkit.

So the biggest improvements over the current binding system are:

  • It will be available at runtime and in builds.
  • It will be, in part, decoupled from the serialization system of Unity.
  • It will allow to target other properties than the “value” of base fields. This also includes style properties.
  • It will support some form of type conversion.
  • It will support two-way bindings, and more generally it will support multiple binding modes.
  • It will have better UI Builder support.

One of the drawbacks of the current system is that it uses SerializedObject & SerializedProperty to drive the binding, which obviously would not work in builds. The new system will use the Properties Module (promoted from the com.unity.properties package) as its backend. What this module allows us to do is to define and visit property bags for given types. By default, property bags are generated using the same rules as the serialization system (i.e. public fields, fields tagged with [SerializeField]), but it also provides additional ways to instrument your data so that you can use fields and/or properties.

Another drawback of the current system is the lack of control you get in defining the bindings. Since the current system can only bind to “value”, you are limited to only use the “bindingPath” to indicate what you want to bind and then calling “myElement.Bind(…)” will make the system do the rest. With the new system, we want to decouple the binding path from the bindings themselves, so instead of calling Bind on an element, which would generate bindings for that element and its sub-hierarchy, you will be able to define each binding separately. This is necessary because the new system will allow multiple bindings on a single element (targetting different properties). It will be possible to define the bindings directly from Uxml files.

The last major drawback of the current system is that you can’t specify a data source, because implicitly, it will use a SerializeObject/SerializedProperty. The new system will allow to provide your own data sources (any C# object), either on the elements or on a binding directly.

Obviously, this is still in development and anything can change, but that is the general direction we’re taking.
Hope this helps!

6 Likes
3

Unity, I am confident you are taking inspiration and are learning from existing other UI frameworks.
Nonetheless, I want to name some stuff worth looking at for inspiration.

  • Vaadin (Java lib to create web UI), I like their Binder API: https://vaadin.com/docs/latest/binding-data
  • Learning from Java enterprise: JSF vs. JSP
  • Android (also using XML layout, similar to UXML)
  • Angular data binding
  • Windows Forms
  • Qt
    etc. etc.

You may also look at other UI libs in the Unity ecosystem and game industry (sure you do!)

  • Noesis Engine
  • Unreal
    etc. etc.

Last time (already some time ago) I looked at data binding in UIToolkit, I was not impressed. However, I don’t know what was putting me off.
Anyway, I am sure you will come up with a good solution if you learn from other frameworks.

4

Does this mean that you will be able to decouple from Unity APIs and use POCOs with patterns similar to those used in WPF for more than a decade like INotifyPropertyChanged interface?

https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifypropertychanged?view=net-6.0

5

Yes, that is exactly what it means.

My preferred workflow for data binding has usually been to create UI view classes that can act as a buffer between the actual data and the UI. That way, I can control when and if the UI needs to be updated and I can decide when and if I want to commit new values to the data. This sort of workflow will be supported by the new system.

We have some ways to define versions for a data source and some ways to notify changes as well. This is likely to be simple at first, but we can iterate and add more features as time goes by.

3 Likes
6

I would like to ask is that data binding solution for UI Toolkit aiming to achieve something at uGUI that u attach a Monobehavior script and u can expose some UI element variable like Image then u can drag and drop directly into variable?

7

Yes. The first iteration will focus on path-based data binding. What this means is that if you have a MonoBehaviour that exposes a Texture2D field, you will be able to set it as a data source on an element and then add a binding (either though code or in uxml) between that field and, for example, “style.backgroundImage”.

1 Like
8

If you want to use runtime data-binding, you can take a look at the package I’m currently working on - UnityMvvmToolkit. It implements all the features mentioned by @martinpa_unity .

In the repository you will find samples showing the package in action. The package is under the MIT license, so feel free to use it in your projects.

5 Likes