v2 beta feedback mega-thread

[JordanMarr]

I got pretty motivated today and ended up rethinking the way the library works.

Design Goals

• I wanted to be able to take advantage of the Avalonia Compiled Bindings for better performance and type checking in the views. The previous DictionaryViewModel brought over from Elmish.WPF was not able to take advantage of this and had to rely on reflection-based bindings.
• I wanted the Elmish view models to behave a little more like a typical view model class. Meaning: I wanted to create view models with actual, bindable properties, while still maintaining the function goodness of the Elmish pattern. So, you should be able to create an instance of an Elmish view model and actually inspect its properties from the outside -- and even read / write to the properties in OOP fashion. The fact that a view model is using Elmish internally should not matter because it's an implementation detail.
• The existing Elmish.WPF DictionaryViewModel was not able to bind to DataGrid row columns. The workarounds on the Elmish.WPF side were pretty cumbersome, imo. Having more typical view models resolves this issue.
• Get back to using the standard Elmish Program module as much as possible as opposed to custom AvaloniaProgram module fns.

Changes:

• Added a new ReactiveElmishViewModel class.
• Elmish.Avalonia now takes a dependency onAvalonia.ReactiveUI.
• The old bindings (i.e. Binding.oneWay) still exist, but they are now only used for the VidewModel.designInstance. (Only Binding.oneWay is used now -- no need to bind commands as this is only used for the design preview.)
  • It looks like we don't need these at all anymore as we can now set the VM directly as the designVM.
• Bindings between the Model and the view model properties are now sync'd behind the scenes using Rx and the new BindModel method.

This is the end result so far. I will probably post a beta tonight or tomorrow. Let me know what you think. 

CounterViewModel

Notes

• Since ReactiveElmishViewModel inherits from Avalonia.ReactiveUI, your Commands (Increment, Decrement and Reset) can be expressed as simple methods without needing to manually wrap them in an ICommand.
• Copilot is really good and creating those VM property bindings based off the model.

[JordanMarr]

@houstonhaynes @daz10000 @kgday @TeaDrivenDev

[JordanMarr]

Here is the ChartViewModel updated to use ReactiveElmishViewModel.
Notice that what was previously a Binding.twoWay is now just a VM property with a get and set. This is much more direct way of "binding" that is easier to understand, imo.

This is now using the standard Elmish Program.withSubscription, and Program.withTermination.
(I think I will need to re-implement terminateOnViewUnloaded fn from the ElmishViewModel module because that is way easier, and this is something that will be done a lot.)

[Jamie-Rower]

I like where this is headed! I had rather hoped from the look of "|> Program.runView this view" that I'd be able to supplant the view with a FuncUI created component, but obviously not that simple. Along the vein of mixing FuncUI components with axaml views, I have used your previous answer (thank you again!) with the new ReactiveElmishViewModel as follows:

TestView.axaml & TestView.axaml.fs : just the basics, but swapping the view content with:

        this.InitializeComponent()
        base.Content <- TestViewModel.testview

testview is defined as a static member of the TestViewModel type as:

static member testview =
        let aboutView = new AboutView()
        Component (fun ctx ->            
            let state = TestViewModel.DesignVM       
            DockPanel.create [
                DockPanel.onPointerPressed (
                    fun _ -> 
                        printfn $"Pointer pressed"
                        //state.Dispatch Msg.DragStart // Runtime Error: Elmish loop has not started
                     )
                DockPanel.onPointerMoved (
                    fun args ->
                        printfn $"Pointer moved {args.GetPosition(null)}"
                )
                DockPanel.onPointerReleased (
                    fun _ ->
                        printfn $"Pointer released"
                )
                DockPanel.children [                    
                    TextBlock.create [
                        TextBlock.dock Dock.Top
                        TextBlock.fontSize 24
                        TextBlock.verticalAlignment VerticalAlignment.Center
                        TextBlock.horizontalAlignment HorizontalAlignment.Center
                        TextBlock.text state.Name
                    ]
                    // I was curious about this, and it works (after some file precedence massaging)
                    // The Ok message within does not, which isn't surprising
                    ContentControl.create [
                        ContentControl.dock Dock.Bottom
                        ContentControl.content aboutView

So it may be that I am just missing something due to my ignorance, but as the TestViewModel.DesignVM is static, it should be valid, no? The compiler has no issue with it, and it displays properly, including the nested About view, but clicking the panel results in: "Dispatch failed because the Elmish loop has not been started.", which is an error message from the ReactiveElmishViewModel if I'm not mistaken.

Should that work? Seems like it would be an easy way to translate mouse events on general controls into Elmish messages, but I'm still kind of fumbling around.

[JordanMarr]

With active development of the core features of v2.0, I don’t have enough mental reserves to even begin to contemplate first class integration with FuncUI.
However, I do think it’s something that other people will be interested in. So if you can get it working in the reverse direction, please do share your findings.

[Jamie-Rower]

Totally understandable. I appreciate your response, and all your work on this package! It is very cool!
I'll repost if I find anything interesting.

[Jamie-Rower]

Just FYI update: What I was really trying to do was get a click event from a non-traditional control and convert it to an Elmish message... in a roundabout way, as it turns out. FuncUI is not required, andI believe your binding changes have helped. It's pretty simple, in the end, so I'm glad you didn't waste any brain power on it.

In the code behind class, you do something like:

        this.InitializeComponent()
        let panel = this.FindControl<StackPanel>("DragPanel")
        ()
        panel.Background <- Brushes.Red
        panel.PointerPressed.Add(fun args -> 
            printfn "Clickity Click" 
            this.DataContext :?> DragViewModel |> fun vm -> vm.DragStart() |> ignore
            )

with the DragStart message defined in the model and bound:

member this.DragStart() = this.Dispatch DragStart

This works perfectly, and I'll be smacking my forehead repeatedly for the rest of the day.

[JordanMarr]

A prerelease v2.0.0-beta is available here:
https://www.nuget.org/packages/Elmish.Avalonia

[kgday]

I was actually contemplating getting rid of that, along with almost everything else copied over from the WPF.Elmish project, since this library has evolved into such a different approach.

That's fair enough.
We could use ReactiveCommands for that matter. Silly me, I missed the fact that ReactiveElmishViewModel inherited from ReactiveObject. I am quite familiar with using ReactiveUI in C# projects and using ReactiveCommand. But I think the DependsOn attribute might make for cleaner looking code so one doesn't have to create an IObservable for the canExecute parameter.

[kgday]

But reading on the DependsOn , you have to trigger a PropertyChanged on the DependsOn attributed property. Perhaps that would be 6 of one and 1/2 a dozen of the other (If that phrase is not too Australian - sorry if it is).

[JordanMarr]

I'm trying to add a conditional CanReset to the CounterViewModel, but no success yet...

[JordanMarr]

This seems to be the easiest way to do it:

[kgday]

That works.

[JordanMarr]

I updated the SampleProject to use Avalonia Compiled Bindings tonight and it works great. It creates a Build error if the VM is missing a property.

Here is the commit that implements it:
e7d8ff7

One of the changes required was that Avalonia doesn’t seem to like having the ViewModel embedded within a module (it causes the path to fail for some reason).

[JordanMarr]

Another nice benefit to the v2 approach of utilizing ReactiveUI is that it makes it very easy to create viewmodels using theReactiveObjectbase class.
This’s could be useful for simple VMs that are little more than a few bindable properties and commands that don’t require the power of Elmish.

[kgday]

Also allow us to have derived properties using ObservablePropertyAsHelper<> class.

[JordanMarr]

I'd love to see an example of this. Curious to see if it will play nicely with the ReactiveElmishViewModel.

[JordanMarr]

You can also do transformation of the Elmish model using the secondary overload of the BindModel method:

[kgday]

True, cool.

[kgday]

I'd love to see an example of this. Curious to see if it will play nicely with the ReactiveElmishViewModel.

I'll work on this over the next few days as I am able to.

[kgday]

How do you handle binding of option types? For example when binding to the selected item of a list box.

[kgday]

According to the docs, can also use {ReflectionBinding on a binding by binding basis with CompiledBindings left on. I'll try that.

[kgday]

Using SelectedIndex is the trick to what I wanted.

[kgday]

The trick will be to not try to bind to option types for reference types at all unless you have access to the reference type to add [<AllowNullLiteral>] to its declaration. The issue was I was trying to set the content property to a ViewModel but if not page is selected, I want to show none. I now have just implemented a 'Blank Page' view and view model to handle that in my experiment.

[TeaDrivenDev]

Depending on the situation, ValueConverters might also be useful for binding option types.

[JordanMarr]

Ah yes, it would make sense for the Elmish.Avalonia lib to have some built-in converters for options, i.e. OptionToBool.

[JordanMarr]

I'm thinking of removing the shorter BindModel overload, so instead of this:

member this.Count = this.BindModel(fun m -> m.Count)

You would always use this overload:

member this.Count = this.BindModel(nameof this.Count, fun m -> m.Count)

The reason is that the first overload is supposed to be a convenient shortcut that both retrieves the value from the Model and also captures the name string of the vm property. However, this only works properly if the vm and model both have the exact same property name.
Where this becomes an issue is when you decide to change it to use a projection of the model, like this:

member this.Count = this.BindModel(fun m -> $"***{m.Count}***")

-- as this will break because it will fail when it tries to parse out the vm property name.

If there was only the longer overload, you could use a projection at any time and it wouldn't matter because it would always have the vm property name supplied.

The convenience of being able to "sometimes" use shorter overload to "type less" is outweighed by the potential "foot gun" of getting a runtime error. Also, Copilot kind of makes the extra typing a moot point anyways as it is really good at boiler plate like this.

[JordanMarr]

It is done!
2.0.0-beta7

[kgday]

Makes good sense.

[JordanMarr]

Sharing models concept

Currently, ReactiveElmishViewModel is an abstract class that expects/requires you to provide a StartElmishLoop implementation. The original assumption being that every VM will run its own Elmish loop.
However, I'm thinking that it might be beneficial to bind a view model against an Elmish loop hosted in another VM.

For example, if you had a parent view/VM that starts an Elmish loop that has a child view/VM that wants to bind to the parent's Elmish loop. In that case, I image that StartElmishLoop should not be required. The child VM should be able to utilize an instance of the parent's Elmish loop, and it should be able to call BindModel and Dispatch against the parent's Elmish context.

This would essentially be very similar to the classic, monolithic Elmish loop, minus the boilerplate of binding everything together.

[houstonhaynes]

@Jamie-Rower and I have been talking about this a bit on the side for our project. I have two things to mention/ask about...

if you had a parent view/VM that starts an Elmish loop that has a child view/VM that wants to bind to the parent's Elmish loop.

1. This immediately made me think/wonder about the "interrupt" pattern for the "Ok" to home that's manage globally for the sample app. Is this the mechanism you're focused on? So this would be about the MainView having a "parent" loop and the individual VM would be the "child". and/or...
2. Jamie and I are nibbling around the edges of the concept of visuals delivered into the view in a component model, where we may "freeze" certain visuals that are inside the VM - while others continue to receive updates.

My point was to more-or-less take a side bar and ask whether my thinking was right about the possibility of nested loops working with/interacting with each other. I have a very strong idea of how this operates within akkanet but I don't want to get it twisted. I've seen this and this and I want to be sure I'm apples-to-apples on the mental model. Thanks!

[daz10000]

Playing catch up here but looks really nice - I like simplicity - proof is always in the elegance of the final code for real world applications and this passes the sniff test. I still have work to do getting the web/wasm demo running - enough things changed in Avalonia that I had to update the template but it's still not quite right. When I'm done with that, I'll pull all this in (the desktop branch should still work fine). Looking forward to trying this on some of my projects!

[JordanMarr]

BindModel looks even better with F#8!

[JordanMarr]

I was messing around with this and I had a breakthrough...
Introducing the new Bind method in v2.0.0-beta11: 🤩🤩

type CounterViewModel() =
    inherit ReactiveElmishViewModel<Model, Msg>(init())

    member this.Count = this.Bind _.Count
    member this.Actions = this.Bind _.Actions
    member this.Increment() = this.Dispatch Increment
    member this.Decrement() = this.Dispatch Decrement
    member this.Reset() = this.Dispatch Reset
    member this.IsResetEnabled = this.Bind(fun m -> m.Count <> 0)

    override this.StartElmishLoop(view: Avalonia.Controls.Control) = 
        Program.mkAvaloniaSimple init update
        |> Program.withErrorHandler (fun (_, ex) -> printfn "Error: %s" ex.Message)
        |> Program.withConsoleTrace
        |> Program.runView this view

    static member DesignVM = new CounterViewModel()

[JordanMarr]

Just a thought, would it be possible to have an overload that took a lamba for the first parameter of BindModel like reactiveui does in its this.WhenAnyValue etc constructs? Probably not without an extension method I guess, which is exactly what the reactiveui WhenAnyValue constructs are.

Yes, I definitely want this or something very similar.
It's also possible that we could try to take advantage of what ReactiveUI has built-in. But TBH, I find it hard to grasp, even though I love working with Rx. So, maybe best to just continue crafting a more custom F# API to sit on top of it.

[houstonhaynes]

I'm glad I'm not the only one that sees Rx as opaque from time to time. 👍

[TeaDrivenDev]

Funny side note on this: The trigger for this current revamp was me asking Jordan a question in a small project I'm using Elmish.Avalonia in. Said project is a port/rewrite of a previous WPF application from a time when I went completely overboard with Rx, where everything is subscribing to everything else, and it's sometimes near impossible to find out where the thing that is currently happening started.

[JordanMarr]

I went through the exact same phase early on with WPF where I had VMs communicating via Rx messages. It became increasingly difficult to reason about logic flow as events were sometimes bounced back and forth from one VM event to the other like a pinball machine. While sometimes helpful, it felt like a bit of an anti-pattern.

Ideally, we can leverage Rx in a way that doesn't overemphasize it.
Every time I look at the ReactiveUI library examples, I come away thinking that it's overly complex (imo).

[kgday]

Introducing the new Bind method in v2.0.0-beta11

Looking forward to seeing that beta. Can only see beta 9 on nuget at present.

[JordanMarr]

It's there -- but it looks like it's being sorted alphabetically, not alphanumerically.

[JordanMarr]

Ah, it looks I need to use SemVer with a dot before the prerelease number.
Republishing as v2.0.0-beta.12. Hopefully that will sort to the top. 😅

[JordanMarr]

We have entered the gamma testing phase.
2.0.0-gamma.1

[houstonhaynes]

LOL - You need a parser and a type checker! 😁

[kgday]

Thanks very much. Brilliant!

[JordanMarr]

I'm experimenting with a few different ways of sharing a single model with multiple views that is pretty exciting.
But I wanted to share this small refactor to the Sample navigation that pulls the "VM" stuff out of the Elmish model.
The difference is that the Main Model stores a new View enum rather than storing the VM itself.
Ideally, the model should stay pure and doesn't become entangled in the VM business.

MainViewModel.fs

namespace AvaloniaExample.ViewModels

open Elmish.Avalonia
open Elmish

module Main = 

    type Model = 
        {
            View: View
        }

    and View = 
      | CounterView
      | ChartView
      | AboutView
      | FilePickerView

    type Msg = 
        | SetView of View
        | Terminate

    let init() = 
        { 
            View = CounterView
        }

    let update (msg: Msg) (model: Model) = 
        match msg with
        | SetView view -> 
            { View = view }
        | Terminate ->
            model

    let subscriptions (model: Model) : Sub<Msg> =
        let messageBusSub (dispatch: Msg -> unit) = 
            Messaging.bus.Subscribe(fun msg -> 
                match msg with
                | Messaging.GlobalMsg.GoHome -> 
                    dispatch (SetView CounterView)
            )

        [ 
            [ nameof messageBusSub ], messageBusSub
        ]

open Main

type MainViewModel() =
    inherit ReactiveElmishViewModel<Model, Msg>(init())

    member this.ContentVM = 
        this.Bind (fun m -> 
            match m.View with
            | CounterView -> new CounterViewModel() 
            | AboutView -> new AboutViewModel()
            | ChartView -> new ChartViewModel()
            | FilePickerView -> new FilePickerViewModel()
            : IElmishViewModel)

    member this.ShowChart() = this.Dispatch (SetView ChartView)
    member this.ShowCounter() = this.Dispatch (SetView CounterView)
    member this.ShowAbout() = this.Dispatch (SetView AboutView)
    member this.ShowFilePicker() = this.Dispatch (SetView FilePickerView)

    override this.StartElmishLoop(view: Avalonia.Controls.Control) = 
        Program.mkAvaloniaSimple init update
        |> Program.withErrorHandler (fun (_, ex) -> printfn "Error: %s" ex.Message)
        |> Program.withConsoleTrace
        |> Program.withSubscription subscriptions
        |> Program.terminateOnViewUnloaded this Terminate
        |> Program.runView this view

    static member DesignVM = new MainViewModel()

[kgday]

This is a similar concept with how bolero and websharper's navigation works by have a state indicator dsu for a page in the model and that state is converted to a view in the view function, here instead of view we are converting to a viewmodel. I am currently working on a in-house line of business app using f# and bolero (and your other great project sqlhydra+sqlhydra.query).

[kgday]

Just checked this out in the v2-beta-IReactiveElmishViewModel branch. Awesome stuff!!

[JordanMarr]

@JordanMarr That wouldn't really be possible in my case with the ObservableCollection holding the ViewModels for the rows in the DataGrid, though, would it?

First, I’m not sure it’s worth the effort to keep the file vms out of the main model.
It’s a lot more convenient to just keep track of them there. keeping them separate would require mapping infrastructure that doesn’t exist.

Next, the file vm should not be using the ReactiveElmishViewModel as that class is designed to be used with a parent view. One big problem with using it as you are currently doing is that each file row spins up it’s own elmish loop that is never disposed (because it was designed to be used with a parent view for disposal).
Since currently there is no “ReactiveElmishSubModel” that has a disposal strategy, you should use a simple ReactiveObject for the file vm.

[houstonhaynes]

This is very helpful to keep a mental model (no pun intended). @Jamie-Rower and I have been talking about our case where a "central" model that is a bunch of ObservableCollections to populate visuals in LiveCharts2.

Those Series would and be used to flesh out the initial views that users would see on initial login. In my mind each series is hydrated by a SingnalR InvokeAsync to the back end to fetch the latest and then a sub into updates that the server side throws forward on its own cadence. So this would in-effect be a form of caching with a bit of Rx on the side.

This is all well and good until the user filters on the data and triggers an "update" which would mean spawning new server-side agents for that user. I don't suppose a new model is called for, just the actors and SignalR channels it's using to feed the model.

Anyway, I was thinking there might be need for a parent and child models - and thinking through how to deal with that in an idiomatic Elmish way. But I might have just answered my own question. 🤔💡😆

[JordanMarr]

Next, the file vm should not be using the ReactiveElmishViewModel as that class is designed to be used with a parent view. One big problem with using it as you are currently doing is that each file row spins up it’s own elmish loop that is never disposed (because it was designed to be used with a parent view for disposal).
Since currently there is no “ReactiveElmishSubModel” that has a disposal strategy, you should use a simple ReactiveObject for the file vm.

Looks like not disposing the ReactiveElmishViewModel may not be a big deal as long as the observable subscriptions stay within the VM (and as long as you're not running any Elmish subscriptions).
From the ReactiveUI docs:
Not all subscriptions need to be disposed...

[hhaynes-rower]

FYI - the sample app when built from v2-beta-IReactiveElmishViewModel is a bit wonky. I've noticed the counter view gets a list of "Set View" Actions. And when navigating between views using the top bar eventually the Chart (and File Picker) don't render any longer - it's just a blank screen. I'm still sniffing around but I thought I'd post this back while it's fresh on my eyes.

[hhaynes-rower]

My question is "how is this even building?" when ReactiveViewModel() isn't defined...

[kgday]

I can see it in that branch (v2-beta-IReactiveElmishViewModel) in ReactiveElmishViewModel.fs line 20.

[JordanMarr]

Oh man, you are brave looking at that branch!

[hhaynes-rower]

LOL - I'm a curious type! FWIW I also just forked Npgsql.AgensGraph which hasn't been updated since 2017 so I'm outside the 2nd standard deviation at both ends of the spectrum. :)

[JordanMarr]

FYI - the sample app when built from v2-beta-IReactiveElmishViewModel is a bit wonky. I've noticed the counter view gets a list of "Set View" Actions. And when navigating between views using the top bar eventually the Chart (and File Picker) don't render any longer - it's just a blank screen. I'm still sniffing around but I thought I'd post this back while it's fresh on my eyes.

yeah, I guess that branch is not ready for prime time. 😕
Lots of cool ideas there, but still some weird behavior for sure. I guess it will just stay as an experiment for now.

[kgday]

@JordanMarr Like what you are developing in the v2-beta-ReactiveViewModel branch, the ElmishStore concept and the fact that the ViewModel can share one or create their own is great! Allows for great flexibility.

[JordanMarr]

Thanks! I'm feeling better about this version so far because it does modularizes the concerns a bit more by using the store concept.
I think tomorrow I might try to make a Nav system to make it easier to reason about the view/vm instantiation, binding and disposal with explicit transient and singleton modes.

[houstonhaynes]

I moved over my views/VMs over to the Example in a fork of your repo and built it out on my own local branch. The map is still behaving oddlly but running five subscriptions to pull data out from a DB seems to be really smooth - as long as I'm running the DB on another machine. 😁

[JordanMarr]

Wow, this is what it looks like using ReactiveUI "DynamicData":

Elmish Model:

    type Model =
        {
            FileQueue: SourceCache<File, string>
        }

Elmish Init

    let init () =
        {
            FileQueue = new SourceCache<File, string>(fun f -> f.FullName)
        }

Elmish Update

        | AddFile path ->
            let file = mkFile path
            model.FileQueue.AddOrUpdate(file) 
            model
        | UpdateFile (file, progress, moveFileStatus) ->
            let updatedFile = { file with Progress = progress; Status = moveFileStatus }
            model.FileQueue.AddOrUpdate(updatedFile)
            model
        | RemoveFile file ->
            model.FileQueue.RemoveKey file.FullName
            model

View Model

type MainWindowViewModel(folderPicker: Services.FolderPickerService) as this =
    inherit ReactiveElmishViewModel()
    
    let mutable _fileQueue = Unchecked.defaultof<_>
    do store.Model.FileQueue.Connect().Bind(&_fileQueue).Subscribe() |> this.AddDisposable
    
    member this.FileQueue = _fileQueue

That's almost a one-liner!

Great suggestion, @kgday.

[JordanMarr]

I think it would be nice if it could be expressed like this:

type MainWindowViewModel(folderPicker: Services.FolderPickerService) =
    inherit ReactiveElmishViewModel()

    member this.FileQueue = this.BindCollection(store, _.FileQueue)

[kgday]

Unless you want to transform from a model to a viewModel. In which case you would use the other notation.

[TeaDrivenDev]

Another aspect that may or may not need specific support on the library side: throttling or otherwise Rx transforming input from bindings before it's dispatched. Think search/filter fields where you only want to have something happen once the user stops typing for half a second and the like.

[houstonhaynes]

@TeaDrivenDev I've been thinking about this for the UI that @Jamie-Rower and I are working on. The phase we're in at the moment is recreating an interactive dashboard (we had originally built with Blazor) that has selectable filter controls at each visual - where each visual's filter selection also informs the scope of all other visuals in the view.

I don't necessarily mind sending accumulations of filter criteria through the loop multiple times as the user selects different controls but I like the idea of holding/queueing those selections to reduce the amount of churn in the back end that would result. With our timescale DB that takes in new events the queries into the store is on the order of hundredths to tenths of a second for spans ranging from one minute to a week. But once longer time scales enter the picture there could be some "chop" in canceling sessions and I'm trying to think my way through that. So thanks for bringing this up. 👍

[daz10000]

good point - I’ve had surprisingly bad experiences with the Elmish pattern (more in React world) doing trivial UI tasks like accepting a barcode scanned input.  The flood of updates killed the event loop and bad things happened.  I haven’t done the equivalent yet in AvalonialandAm 11/21/23 um 9:34 PM schrieb TeaDrivenDev ***@***.***>: Another aspect that may or may not need specific support on the library side: throttling or otherwise Rx transforming input from bindings before it's dispatched. Think search/filter fields where you only want to have something happen once the user stops typing for half a second and the like. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[kgday]

In bolero, for throttle I add an event or subject on the model and subscribe to it using the elmish Program.withSubscription with a Observable.throttle inside that. When an input (edit box) changes, the dispatch message on update simply triggers the event plus updating the model field. The throttled subscription then does the search. I guess this could be achieved within a viewmodel without this setup using the ViewModel.Subscribe maybe?

[JordanMarr]

v2.0.0-gamma.6 is released.

• Adds BindSourceList and BindSourceCache methods
• Adds SourceList and SourceCache helper modules (for convenience)
• Updated Counter and Chart samples
  • Counter and Chart now use SourceList for model.Actions (which fixes issue where table was rebuilt on every update which reset scroll position)
  • Chart Series remains an ObservableCollection and that is now bound directly to the VM property

[houstonhaynes]

Thanks for the update - I'm looking forward to taking a look at the latest.

I thought I'd drop this in just for context on "where it started" for me.

https://livecharts.dev/docs/Avalonia/2.0.0-rc2/CartesianChart.Cartesian%20chart%20control#axes.labels-and-axes.labelers

I'm not over-committed to LiveCharts but they definitely have a lot to offer my current project. I've also done quite a bit with HighCharts but mostly with R and JS - and while I'm not against JS-wrappers I'd like to stay .NET native as much as possible. Anyway, my focus here is to grok as much as I can in the vein of what @daz10000 mentioned with limits in the Elmish loop.

To zoom out a bit (and toward that latter point) my long-term goal really leans heavily on a back end - I'm mainly imagining SignalR marshaling all of the information through actors and feeding it into a queue that puts all of the elements of the model and sends it up in one hub "push". That renders some of the subscription 'breadcrumbs' I've followed moot, but it's a step. This weekend I'll be working on standing up a hosted service on the back end to do the querying of the data source and posting results to a hub that the SignalR client then picks up and updates the model.

The end result I'm looking for is to make the client as "thin" as possible, if that makes sense. But I also want to have options to make it "as thick as necessary" when needs arise. You know - have it both ways 🍰 Anyway, that's just a quick digression for context so if you see me leaning on a "tech crutch" too hard don't be shy about expanding my horizons a bit. 🌤️ 😄

Thanks again for doing this labor - both of finding new paths forward and for the educational lift in dragging me along. 😉

[JordanMarr]

My goal is for F# / community to have lots of nice things. 😎
It's especially fun to have nice things for UI development since WPF was such a sore spot for F# users. Even if you used the Elmish.WPF library, you still had to create a C# project to house your xaml views. I'm glad Avalonia made it a point to include F# templates OOTB.

[TeaDrivenDev]

My previous projects were in WPF using FsXaml; that worked and avoided the need for a C# project, but it had its limitations and required weird workarounds for some stuff. Seeing how well Avalonia works with F# is great, down to things like being able to directly use DU cases as converter parameters, while WPF required them being mapped to normal enums.

[houstonhaynes]

FYI- adding this to my drive time playlist 🦃🛣

https://youtu.be/hLjqf4PmG9E?si=WG2HMPDz2tqVo1cA

[houstonhaynes]

My post drive take on this... lots of good history and some plans to play well with .NET 8 and Avalonia. 🤷‍♂️🤷‍♀️

[TeaDrivenDev]

@JordanMarr With the changes you've made to the way the file picker is called, there's now no example anymore that shows how to use commands. There should probably be something that demonstrates that.

Related: How would I run code when the application is closed, like e.g. saving settings on shutdown? I tried issuing a command when handling the termination message, but that appears to be too late, as the breakpoint inside that isn't hit when closing the window.
Running something on startup (e.g. loading settings) would be done by issuing a command from the init function, I suppose?

[JordanMarr]

You can handle the desktop application Startup, Exit and ShutdownRequested events.
From there, you can call whatever, or even dispatch to your main App store if you want.

[TeaDrivenDev]

That works for the purpose; thanks!

[JordanMarr]

Currently, the CompositionRoot base class is using reflection to scan the assembly for view models.
I wonder if that should be optional since .NET 8 is slowly moving away from reflection.

[houstonhaynes]

The faster .NET "slowly" moves away from the potential for hidden shared state, the better. 🤔🤓

[JordanMarr]

v2.0.0-gamma.7 released with some subtle changes around giving the ability to avoid use of reflection, while still using reflection by default for a smoother user experience:

• CompositionRoot - RegisterServices:

  • If not overridden, this method will still default to scanning the assembly for VM types and registering them as DI services.
  • If overridden, user must now explicitly call base.RegisterServices to scan assembly for VMs. This at least gives them the option to manually add them without using reflection.

• CompositionRoot - RegisterViews:

  • Added new overloads to View.Singleton() and View.Transient() static methods to allow user to explicitly provide a createView function if they want to avoid use of Activator.CreateInstance.
  • Added xml comments to all overloads to explicitly mention which overloads will use Activator.CreateInstance.

• Sample AppCompositionRoot was updated to include the call to base.RegisterServices:

namespace AvaloniaExample

open Elmish.Avalonia
open Microsoft.Extensions.DependencyInjection
open AvaloniaExample.ViewModels
open AvaloniaExample.Views

type AppCompositionRoot() =
    inherit CompositionRoot()

    let mainView = MainView()

    override this.RegisterServices services = 
        base.RegisterServices services |> ignore
        services.AddSingleton<FileService>(FileService(mainView))

    override this.RegisterViews() = 
        Map [
            VM.Key<MainViewModel>(), View.Singleton(mainView)
            VM.Key<CounterViewModel>(), View.Singleton<CounterView>()
            VM.Key<AboutViewModel>(), View.Singleton<AboutView>()
            VM.Key<ChartViewModel>(), View.Singleton<ChartView>()
            VM.Key<FilePickerViewModel>(), View.Singleton<FilePickerView>()
        ]
        

[houstonhaynes]

Help me understand something - I set up ChartView as View.Transient but the subscriptions continued to cycle when I switched to a new view. Is there something else I should have done?

[JordanMarr]

Help me understand something - I set up ChartView as View.Transient but the subscriptions continued to cycle when I switched to a new view. Is there something else I should have done?

Two things:

1. Try again with v2.0.0-gamma.8 that I just released as there was a small bug fix to Transient.
2. You will still need to terminate your subscriptions using |> Program.mkStoreWithTerminate this Terminate, so make sure you are calling that instead of |> Program.mkStore. (The current sample app is using Singleton views, and so there was no need to terminate the subscriptions.)
3. You can also drop the Subscribe that was "Disabling Chart AutoUpdate", as that was just a way to stop the chart when running the ChartView as a Singleton that was never fully Terminated/Disposed.

You should end up with this:

type ChartViewModel() as this =
    inherit ReactiveElmishViewModel()

    let app = App.app

    let local = 
        Program.mkAvaloniaSimple init update
        |> Program.withErrorHandler (fun (_, ex) -> printfn $"Error: %s{ex.Message}")
        |> Program.withSubscription subscriptions
        |> Program.mkStoreWithTerminate this Terminate 

    member this.Series = local.Model.Series
    member this.Actions = this.BindSourceList(local, _.Actions)
    member this.AddItem() = local.Dispatch AddItem
    member this.RemoveItem() = local.Dispatch RemoveItem
    member this.UpdateItem() = local.Dispatch UpdateItem
    member this.ReplaceItem() = local.Dispatch ReplaceItem
    member this.Reset() = local.Dispatch Reset
    member this.IsAutoUpdateChecked 
        with get () = this.Bind (local, _.IsAutoUpdateChecked)
        and set value = local.Dispatch (SetIsAutoUpdateChecked value)
    member this.XAxes = this.Bind (local, fun _ -> XAxes)
    member this.Ok() = app.Dispatch App.GoHome

    static member DesignVM = new ChartViewModel()

[houstonhaynes]

Thanks. I did miss the swap out to use the .mkSToreWithTerminate 😊

[JordanMarr]

v2.0.0-gamma.8

• Adds new BindOnChanged method which lets you specify a model property (or properties) to check for changes before evaluating the modelProjection function. This was added to avoid evaluating an expensive model projection more than once. For example, when evaluating the current ContentView property on the MainViewModel. Using Bind in this case would execute the modelProjection twice: once to determine if the value had changed, and then again to bind to the property. Using BindOnChanged will simply check to see if the _.View property changed on the model instead of creating the actual view twice.
• Updated the MainViewModel sample:

namespace AvaloniaExample.ViewModels

open Elmish.Avalonia
open App

type MainViewModel() =
    inherit ReactiveElmishViewModel()
    
    member this.ContentView = 
        this.BindOnChanged (app, _.View, fun m -> 
            match m.View with
            | CounterView -> this.GetView<CounterViewModel>()
            | AboutView -> this.GetView<AboutViewModel>()
            | ChartView -> this.GetView<ChartViewModel>()
            | FilePickerView -> this.GetView<FilePickerViewModel>()
        )

    member this.ShowChart() = app.Dispatch (SetView ChartView)
    member this.ShowCounter() = app.Dispatch (SetView CounterView)
    member this.ShowAbout() = app.Dispatch (SetView AboutView)
    member this.ShowFilePicker() = app.Dispatch (SetView FilePickerView)

    static member DesignVM = 
        new MainViewModel()

[JordanMarr]

I started a thread for README feedback here:

#30

[JordanMarr]

v2.0.0-gamma.9

• Removed Root property from ReactiveElmishViewModel, opting to inject CompositionRoot when needed instead.

type MainViewModel(root: CompositionRoot) =
    inherit ReactiveElmishViewModel()
    
    member this.ContentView = 
        this.BindOnChanged (app, _.View, fun m -> 
            match m.View with
            | CounterView -> root.GetView<CounterViewModel>()
            | AboutView -> root.GetView<AboutViewModel>()
            | ChartView -> root.GetView<ChartViewModel>()
            | FilePickerView -> root.GetView<FilePickerViewModel>()
        )

[JordanMarr]

Big changes!

After realizing that this solution is way better than what I was doing on my current WPF project (C#), I wanted to utilize this library there too.
Looking at the code, I realized that it would be pretty easy to refactor into a "core" package, so that's what I did this evening.

• New ReactiveElmish package will contain the core of the v2 beta development; namely, ReactiveElmishStore and ReactiveElmishViewModel.
• Elmish.Avalonia will be renamed to ReactiveElmish.Avalonia
• I also created ReactiveElmish.Wpf - both to use with my pre-existing project and to prove to myself how easy it would be to do.

This is my C# code calling an F# global app store:

    public ICommand IncrementCmd => new RelayCommand(Increment);
    public ICommand DecrementCmd => new RelayCommand(Decrement);

    public int Count => Bind(_store, App.bind(m => m.Counter));

    public void Increment() => _store.Dispatch(App.Msg.Increment);
    public void Decrement() => _store.Dispatch(App.Msg.Decrement);

It works great! I think that F# might be appealing to all the CSharpers out there that have heard F# is great for modeling and would like to try their hand at discriminated unions!

[TeaDrivenDev]

(If this is what happens when I ask Jordan how to bind ViewModels to DataGrid columns, it may be worth it to come up with some bigger questions. Imagine all the stuff we might get.)

[JordanMarr]

ReactiveElmish.Avalonia v1.0.0-beta.1 is now published to NuGet!

If you ever decide you want to use the base ReactiveElmishStore and ReactiveElmishViewModel alone without any of the opinionated app config in this package (CompositionRoot with view registration and Microsoft.Extensions.DependencyInjection, etc), you can roll your own with the ReactiveElmish package (which now lives here and has its own NuGet package).

[JordanMarr]

Interesting. What a strange looking API.

I think I can add a Bind method overload to make this a little nicer.
Your project is coming along nicely! I like the simplified FileViewModel that calls the store directly.

[TeaDrivenDev]

Thanks! I think it could eventually be useful as a kind of basic "canonical" real-world end-to-end demonstration of using the library.

[TeaDrivenDev]

I'm finding there's sometimes a bit of an impedance mismatch between "idiomatic" (as much as I can tell) use of Dynamic Data and the idea of clear separation of model and ViewModel layers, in terms of the behavior in practice. In the above example, every change in the values of a file leads to the creation of a new FileViewModel instance, which then replaces the previous one in the resulting ReadOnlyObservableCollection. That will probably be unproblematic in a lot of scenarios but it e.g. messes up situations where selection in a DataGrid plays a role, and also causes issues with scroll position.

[JordanMarr]

Yeah, I think some more work is needed to better integrate the DynamicData collections. But I’m not quite sure what it should look like yet.

[TeaDrivenDev]

I might have a look at how it behaves if instead of always creating a new ViewModel for each change, I cache them on creation and return update and return the existing one in the .Transform() call if found. Although.... that seems a bit like working around DynamicData instead of with it.

[kgday]

There is a transform extension method called TransformWithInlineUpdate for IObservable<IChangeSet<TDestination, TKey>>, which instead of recreating the transformed object each time, it matches the key and updates if exists. It is in the ObservableCacheEx.cs if you are looking in the source.

[TeaDrivenDev]

That may be what I'm looking for; thanks.

[JordanMarr]

v1.0.0-beta.3

• Updated BindSourceCache and BindSourceList methods
  • BindSourceCache now has an option a map and a sortBy
  • BindSourceList now has an optional map
• Added TodoList sample that uses Elmish commands

Look at the samples to see the slightly different syntax to call BindSourceCache and BindSourceList methods.

It's not perfect, but maybe a slight improvement. I'm sure there will be more changes around the DynamicData stuff.

[Jamie-Rower]

This is awesome! I love the changes.

I have a question about binding. I'm building a generic radial slider as a templated control, which is then being used by an Elmish view, with a value binding from the model. This is working out to the control, and the control is properly triggering property changed events, but the two way binding isn't working. I have a workaround by adding a handler to the property changed event in the code behind that calls an elmish command to update the model, but this is a bit clunky. I had rather assumed that the two way binding would pick up this event and change the model, but I am uncertain if that is true? It does not seem to be the case, which leads to the question of if there is a "proper" way to handle this?

For reference, the control is invoked from the elmish view:

                                   RingColor="Blue" 
                                   Value="{Binding Number, Mode=TwoWay}"
                                   ArcStart="0" 
                                   SliderWidth="200.0" />

and the workaround:

let slider = this.FindControl<RadialSlider>("BlueRing")
        slider.PropertyChanged.AddHandler(fun (sender : obj) (args ) -> 
            match args.PropertyName with
            | "Value" -> 
                let value = sender :?> RadialSlider |> fun x -> x.Value
                this.DataContext :?> DashboardViewModel |> fun vm -> vm.NumberChanged(value) |> ignore
                printfn $"Value Changed: {value}"
            
                this.InvalidateVisual()
            | _ -> ()
            )

this works, but is far from ideal. Any thoughts, or obvious mistakes?

[TeaDrivenDev]

You also shouldn't need the whole INPC stuff in the control then, as the AvaloniaProperty should take care of that by itself. (I assume you added that in the attempt to solve the issue.)

Interesting though that the two-way binding didn't throw without a setter on the property.

[Jamie-Rower]

yeah, that was my temp fix as I stumble around. I would have expected an error as well - sure isn't shy about that most of the time. Thank you!

[JordanMarr]

Interesting though that the two-way binding didn't throw without a setter on the property.

That is interesting. Unless Compiled Bindings have been disabled, I would have expected them to display a build error.

[Jamie-Rower]

CompiledBindings is set to true in the project file

[Jamie-Rower]

In other news - though I think this is just the control not getting refreshed - If I put up 2 sliders, both bound to the same Number, and a textblock also bound to the number, changing either slider updates the block, but not the other slider. I suspect that is something else though

[JordanMarr]

I think I am ready to merge to the main branch and release as v1 tomorrow.