There is a use of integral bindings where multiple initial model values are provided - there are the in-component defaults of
and then the subcomponent initial defaults of
We see something bizarre happening, that during fluid.notifyInitModelWorkflow somehow the "new" and "old" model values are reversed - the relays are notified as if the in-component defaults are the upcoming new values, overwritng the subcomponent defaults. However, once the component actually finishes initialising in ChangeApplier.initiate.commit, we see the initial and final models the right way round, and regular model listeners are notified in the ordinary way. This makes integral bindings pretty unusable in this case. #
The workaround is to remove the in-component default values, e.g. editorString: "" in youme.demos.console.textareaWithError and jsonString: "" in youme.demos.console
In progress in https://github.com/continuing-creativity/youme/pull/2/files#diff-a133c4af0eace1a751ecd7cc8a393c78a6d11f723172b22386399a38a856705bR37 -
There is a use of integral bindings where multiple initial model values are provided - there are the in-component defaults of
and then the subcomponent initial defaults of
We see something bizarre happening, that during fluid.notifyInitModelWorkflow somehow the "new" and "old" model values are reversed - the relays are notified as if the in-component defaults are the upcoming new values, overwritng the subcomponent defaults. However, once the component actually finishes initialising in ChangeApplier.initiate.commit, we see the initial and final models the right way round, and regular model listeners are notified in the ordinary way. This makes integral bindings pretty unusable in this case. #
The workaround is to remove the in-component default values, e.g. editorString: "" in youme.demos.console.textareaWithError and jsonString: "" in youme.demos.console