trying to write a new Avalonia Property type

[BenMakesGames]

I'm taking some big stabs in the dark here, but I'm attempting to write a new Avalonia property type, to allow for observable dependency properties. the reason being that I think I can achieve a happier dev experience (less boilerplate) when writing dependency properties by using observables. maybe I'm totally wrong, but won't know without trying :P however, I'm running into trouble implementing this... a combination of barely knowing what I'm doing + I think being blocked by some internal virtual methods...

the code I have so far looks like this:

    public class AvaloniaBehaviorSubjectDirectProperty<TOwner, TValue> : DirectPropertyBase<TValue> where TOwner : IAvaloniaObject
    {
        private BehaviorSubject<TValue> Property { get; }

        public AvaloniaBehaviorSubjectDirectProperty(string name, BehaviorSubject<TValue> property, AvaloniaPropertyMetadata metadata)
            : base(name, typeof(TOwner), metadata)
        {
            Property = property;
        }

        public override Type Owner => typeof(TOwner);

        override TValue InvokeGetter(IAvaloniaObject instance) => Property.Value;

        override void InvokeSetter(IAvaloniaObject instance, BindingValue<TValue> value) => Property.OnNext(value.Value);
    }

the idea is to allow a dev to create a BehaviorSubject dependency property in a view, and handle the messy registration via code generation, or some-such (not there yet; again, I barely know what I'm doing here; just playing, at this point.)

a couple questions:

1. does what I'm doing seem even remotely reasonable/like the right approach?
2. assuming this is reasonable: I seem unable to implement the virtual methods InvokeGetter and InvokeSetter, I assume because they are internal. I've done inheritance and abstract classes and things many times, but rarely have used internal, and rarely while poking so deep at a third-party library I'm still trying to understand :P I guess the question is: am I doing it wrong? is there another way? should I be extending AvaloniaProperty<TValue> instead of DirectPropertyBase<TValue>? I feel at a loss

[maxkatz6]

First of all, DirectProperty is not common type of properties to use. It's recommended to use StyledProperty everywhere, unless you need readonly properties (DirectProperty has it) or has some performance concerns (DirectProperty uses single field to store the value, while StyledProperty uses values store-dictionary with multiple priorities that can be added and removed simultaneously). For the same last reason, you can't set DirectProperty with multiple Avalonia styles.

On other hand, that means it's not possible to represent full-featured Avalonia property with single BehaviorSubject, that keeps only one value at a time.

should I be extending AvaloniaProperty instead of DirectPropertyBase

If I were you, and still wanted to implement new property kind, I would go with AvaloniaProperty or AvaloniaProperty.

[maxkatz6]

the idea is to allow a dev to create a BehaviorSubject dependency property in a view, and handle the messy registration via code generation, or some-such (not there yet; again, I barely know what I'm doing here; just playing, at this point.)

Still, I am not sure if it worth the effort, to be honest.
Is the main goal to have one-line property (of Subject type) and code generate everything else?
Or is having the "subject property" by itself is the goal?

[maxkatz6]

From my experience I haven't need to create a lot of components that actually require additional bindable/styleable properties on business projects.
But in case of shared control libraries, just like Avalonia.Controls, we, of course, need it a lot.

[BenMakesGames]

that's counterintuitive to me, and maybe it's just something I have to get used to.

I try to always start from a place of "write code that is easy to reuse". from that point of view, it's reassuring to hear you say that user control properties encourage reuse, since that was the impression I was gaining (and why I started down this path), but discouraging to hear that it's expected to be difficult to go this route. as a developer, I want it to be as easy as possible to write code that can be reused as easily as possible.

I expect there's something that just hasn't clicked with me yet, on how to accomplish this within WPF and/or AvaloniaUI. I'm sure that, in part, my background in component-based frameworks is blocking me from seeing the WPF/AvaloniaUI "way".

[maxkatz6]

I want it to be as easy as possible to write code that can be reused as easily as possible

Still, even with single DataContext input you can create perfectly reusable controls. With one difference - instead of passing multiple properties you need to pass one object, that describes information required for this control.
I.e., instead of "FileName", "FileSize" props you pass single FileInfo(FIleName, FileSize) as a data context. That how it's commonly done in WPF/Avalonia and does not require additional properties usually. Somebody might want to add some additional property for View-only logic, that shouldn't be part of Data/Business/ViewModel (whatever you call it) layer, which is fine, but in Avalonia you can have style classes for that (just like in CSS).

[maxkatz6]

And returning to the common controls, such as Button, TabControl, TextBox and others, they don't have single model that can be described with single object (unless you map literally everything). Moreover, they are required to be flexible as possible and work with styling system (including multiple values for single property, depending on priority and other conditions). For them there is no other way but use multiple Avalonia Properties.
It would be nice to have some kind of source generators, I agree, but I don't see any convenient solution so far.

[BenMakesGames]

I haven't encountered the styling system yet, but I do greatly appreciate the added flexibility (and strong-typing) of separate properties.

I played around with Mobile Blazor Bindings on Friday. it seems they've done something similar to AvaloniaUI, in reimplementing the base components - StackLayout, etc - while allowing custom controls with dead-simple parameters and DI, but I don't really understand how either of these frameworks works on a low level. [edit] correction: I spent a day playing with it, and it's not a reimplementation of XAML. I think I was getting it and Blazor Desktop confused. with Mobile Blazor Bindings, once you're in a Blazor/web component, you're limited to using only more Blazor/web components.