Elmish.Avalonia

[JordanMarr]

High-level description
I have created an "Elmish.Avalonia" branch that ports Elmish.WPF to work with Avalonia.

It seems to work nicely so far!
I'm assuming that it should live in this repository, but I guess that's what I am asking. Thoughts?
(@TysonMN, I already know you are currently busy this week, so no need to rush. I'm hoping others will weigh in as well.)

Cross referenced threads include:

• issue 34 where @Zaid-Ajaj asked for Avalonia support
• issue 1803 on Avalonia UI where @cmeeren mentioned this very thing along with the possibility of refactoring Elmish.WPF to accommodate.

Benefits
Avalonia.FuncUI already exists (I am a maintainer there) and is fantastic. So then why make an Elmish.Avalonia port?

• Some people may prefer using xaml (and it can be an easier sell for some teams)
• Bindings have to be created for controls. Some controls (such as the DataGrid) are too "OOP" and are difficult or impossible to create bindings for. This makes a library like Elmish.Avalonia very useful.
• There is not currently a reliable design preview tool (there is a very experimental project, but the author has stopped working on it and it's way too complex for me to want to mess with it). For me to do any kind of real project work with Avalonia and F#, I feel that a design preview is a necessity. After recently trying Elmish.WPF, I fell in love with the designVM preview functionality.

Other reasons:

• Avalonia UI is about to make a big announcement within the next week, so it's always nice for F# community to be able to participate in the latest and greatest with as many options as possible.
• Avalonia already provides templating to create an F# MVVM solution that includes creating .axaml views within the same project!
• The "Avalonia UI for Visual Studio 2022" extension provides a xaml preview pane that works with F#! 😄
• The Elmish.WPF "designVM" concept works with this extension very well 😄
• Keeping with tradition that the F# community will provide important libraries, developer tools and workload support.

[marner2]

Just thought I'd drop this in here, I've been working on an update that allows for bindings to be specified as static view model types rather than list of string bindings (tracking in issue #494 - I need to update it). This allows the WPF previewer tool to autocomplete bindings in the Design UI, as well as some other advantages (explicit types for Data Templates, etc).

I'm curious if this also affects Avalonia's tooling.

[JordanMarr]

Avalonia supports that out of the box, but you can also implement their IPropertyAccessorPlugin interface to handle other binding strategies as I have done here:
https://github.com/JordanMarr/Elmish.WPF/blob/elmish-avalonia/src/Elmish.Avalonia/AvaloniaPropertyAccessorPlugin.fs

So, I believe it could definitely be modified to use your new strategy.