[Reactive] Generated bindable code depending of the kind of the value

[dr1rrb]

When we declare a Feed<T> in a model, depending of the kind of T the generated code won't be the same:

When T is a primitive (ValueType or string)

We assumed that the typical usage of such feed would be for direct 2-way bindings like for a settings page, so we only generate a plain property.

// Model:
public class MyModel
{
    public IFeed<string> MyProperty { get; }
}

// Bindable
public class BindableMyModel
{
    public string MyProperty { get; set; }
}

When T is a record

This is the common case we want to support and which allows the best experience.
We generate proxies that allows 2-way bindings to each (sub) properties, but which also implements IFeed<TRecord> .

// Model
public partial record MyRecord(string MyValue);
public class MyModel
{
    public IFeed<MyRecord> MyProperty { get; }
}

// Bindable
public partial class BindableMyRecord : IFeed<MyRecord>
{
    public string MyValue { get; set; }
}
public class BindableMyModel
{
    public BindableMyRecord MyProperty { get; }
}

When T is a class

As there is no way to clone the T when a sub property is changed, we only expose it as a IFeed<TClass>

// Model
public partial class MyClass
{
    public string MyValue { get; }
}
public class MyModel
{
    public IFeed<MyClass> MyProperty { get; }
}

// Bindable
public class BindableMyModel
{
    public IFeed<MyClass> MyProperty { get; }
}

Usage in view

The issue with all those different cases is that it make the usage in application way too difficult as depending of the kind of T you cannot use it the same way:

	FeedView	direct binding
primitive	NO	YES
record	YES	YES
class	YES	NO

And even for record, as we are using proxies instead of concrete types, if we want to set an instance of the record from the view (instead of editing it property per property, eg. for selection) we have to data-bind to a magic Value property.

Proposed solution

We should instead make sure that no matter the kind of T we should be able to use it in direct binding and FeedView. This would be possible by changing the generated code to always generate a BindableXXX (or a generic Bindable<T>) no matter the kind of the value, then allow implicit conversion to T:

1. In code (CSharpMarkup): Implement implicit cast operators [MVUX] Implicit cast of generated Bindable<Record|List> #465
2. In XAML (binding engine)
   • Uno's binding engine supports the TypeConverter, so could dynamically convert to T when the desired type is not a ISignal<IMessage> (the type of the Source DP of the FeedView)
   • Windows we could take advantage of the support ICustomPropertyProvider to support a fake MyProperty_Feed property that would be implicitly requested by the FeedView. It would then return either the T or the BindableT for the MyProperty property to allow 2-way direct binding.

Cons:

• The FeedView would have specific support for the generated code.
• Generated code would be more complex.

Why not make a distinction between IFeed and IState, and generate only IFeed for IFeed properties (usable with FeedView) and generate proxies for IState (usable with direct binding)?

It has been determined that it's common to mix a FeedView with a direct binding (e.g. the title of the page).

Why not always generate both T MyProperty and IFeed<T> MyProperty_Feed ?

1. This would make the code less readable when using CSharpMarkup
2. When using 2-way direct binding user would have to use the MyProperty_Feed property for changes to be reflected in the model

Is {x:Bind} will still be supported?

TBD