I discovered that in some cases, it would be nice to be able to observe changes to a channel as an object. But a channel is a mutable type and does not report such changes (or others cannot obtain this information). Would it be possible to implement some kind of interface or something similar so that other objects could handle onChange on channels when something happens in them?
For context: I use DataTemplate from Avalonia, and all data nicely ‘flies through’ the widget. But it turns out that DataTemplate reacts normally to onChange and essentially only works with immutable types.
It is difficult to explain, and its applications are very limited.
If it were possible to track ‘onChange’ on a channel, that would solve some very specific Avalonia problems. However, I’m really not sure now. This type of problem should probably be solved on the Avalonia side.
If it is impossible or difficult to implement, it should not be considered worthwhile.
For context: I use DataTemplate from Avalonia, and all data nicely ‘flies through’ the widget. But it turns out that DataTemplate reacts normally to onChange and essentially only works with immutable types.
DataTemplate is kind of a builder function that triggered from code behind would look something like:
foreach (var item in data)
{
control.DataTemplate = dataTemplate.Build(item);
}
The instance itself is just class with single method.
If you want props inside of data template to react on changes, you need to pass some sort of class instance or channel inside, and use Binding node or apply channel directly. Since there is no update inside of data template you need something that would explicitly call set on prop inside of some reactive region.
The issue you might be hitting also, that all the inputs on controls in Avalonia are cached by VL.Avalonia wrappers. I don’t know might be would be a better approach to convert every input to Channel in Avalonia instead of Optional, since Avalonia uses reactive everything pattern, so most of props are reactive bindable by default…
I suspect that we should close this discussion, as there is no basis for it. We discussed the problem I wanted to solve directly with @antokhio, and he has already found a solution and probably implemented it in the code base.
