This is what I was originally looking for when testing Data Binding. A class that I could put on a UI control and have it connected to the wanted data.
From a user perspective I´m thinking “This slider should connect to this data”, and in my mind the default for that connection would be a two way communication. I did not realise then that to do it just one way would be preferable in some cases. To do this both ways now I add 2-3 classes on a slider and set the data connection up on each to accomplish one thing: Hook up a control to a value.
I think how I would wish for it to work is that you Add one DataBindSlider class to a slider game object, select the data path and then you have 2 toggles. "Update Data" and "Update UI" Then if I make for example a health bar I could just uncheck "Update Data" since I would always set the data value elsewhere.
I would ideally not name the toggles "Getter" and "Setter" since I always get confused by such names. A toggle can set a value in the Data, and the Data can set the value of a toggle. The other way around is also true, the toggle can get its value from Data and the Data can get its value from the toggle. At least if you do not know how the code works but just see it a binding of the two. Also if you put the script on the slider game object directly it can be confusing to have names that are from the data perspective, so the names should be clear from any place in the hierarchy.
For me a lot of UI would work both ways. Input Fields, sliders, toggles. I am storing a bunch of different settings in Context classes that are serialised as xml files, and when deserializing those files I assign the newly loaded Context to a Context Holder and the UI updates all controls. Then the user updates data by using the controls.
I realise that it might already be possible to add this yourself? Anyway I believe that it would provide great value to customers to have such Classes for the most basic Unity UI controls like InputFields, Sliders and Toggles.