I think the binding is a bit surprising: - I expected to be able to create a bidirectional binding ...

# kvision

[jschneider]

I think the binding is a bit surprising:

• I expected to be able to create a bidirectional binding to the ObservableState. Currently I have to add a manual
• It is very surprising to have the "init" lambda every time the value of the ObservableState changes. Coming from TornadoFX I expected the lambda to be just called once - when initializing the text field
• Having to add "value = it" to the init lambda has also been surprising for me.
--> Data Binding is one of the most helpful features. Currently it takes quite a lot of code for each field (compared to e.g. TornadoFX). Maybe there could be some improvements made?

[Robert Jaros]

If you have some ideas please share how would you like it to work.

[jschneider]

I will - at least if I can come up with some ideas 😉

[Robert Jaros]

Databinding is explicit and unidirectional at the moment. But I can think about bidirectional binding for form controls.

[Robert Jaros]

It's easy when you think about the state with a single value (eg. double). But it gets more complicated when the state is complex. The current implementation indeed requires you to do value = it, but at the same time allows to do value = somethingelse(it) 😉

[Robert Jaros]

Notice that form fields are observable values as well. You can subscribe, bind to them or convert them to Flows directly.

[Robert Jaros]

I'm experimenting with bidirectional binding and this is working quite well (it addresses all your three issues):

val state = ObservableValue(5.5)
                    rangeInput(state) {
                        step = 0.1
                        console.log("called once with value $it")
                    }
                    div(state) {
                        +"Current value: $it"
                    }

I consider implementing this for all form controls, but I don't know what to do with currently implemented functions (they get shadowed unless I change the name of the function e.g. rangeInputBind(state) which I don't like).

[Robert Jaros]

I could just drop unidirectional bindings for form controls (as a breaking change for 4.x) but I'm not sure yet.

[jschneider]

You should maybe take a look at TornadoFX. There exist the same problems. With a lot of surprising overloads / method names

--> It should be possible to do it better than tornadofx does. But the ideas there are great


What about binding in a second step with an extension method?

text("Name"){
//some configuration that is only called once
}.bindBidirectional(state)

[jschneider]

Unidirectional bindings are definitely useful.

[jschneider]

I also like that subscribe stuff - just not for alle cases.

[jschneider]

text("Name"){
//some configuration that is only called once
}.bindTo(state)

[jschneider]

this should scale quite well with other use cases

[Robert Jaros]

I'll experiment a bit more and try to find the best solution. Unfortunately never used tornadofx.

[jschneider]

In TornadoFX it is also necessary to provide the property within the constructor (or DSL call).

I don't think this is the best idea. It requires loads of overloaded methods...
I think "fluent" calls could be better. But I don't know for sure

[jschneider]

same think for stuff like validators. Would be great if is possible to add them as kind of "extension"