adding LiveCharts2 to a view (RenderLoop error?)

[houstonhaynes]

I have forked this repo and am trying to add a chart based on the (C#) sample on the LiveCharts2 site.

I've done my best to muddle through (with some support on the F# Discord) and can get things to "compile" - BUT the reason for the quotes is that when I run Debug I get an unhandled exception:

Unhandled exception. System.MissingMethodException: Method not found: 'Void Avalonia.Rendering.RenderLoop..ctor()'.
   at Avalonia.Native.AvaloniaNativePlatform.DoInitialize(AvaloniaNativePlatformOptions options)
   at Avalonia.Native.AvaloniaNativePlatform.Initialize(IntPtr factory, AvaloniaNativePlatformOptions options) in /_/src/Avalonia.Native/AvaloniaNativePlatform.cs:line 32
   at Avalonia.Native.AvaloniaNativePlatform.Initialize(AvaloniaNativePlatformOptions options) in /_/src/Avalonia.Native/AvaloniaNativePlatform.cs:line 55
   at Avalonia.AvaloniaNativePlatformExtensions.<>c__DisplayClass0_0.<UseAvaloniaNative>b__0() in /_/src/Avalonia.Native/AvaloniaNativePlatformExtensions.cs:line 13
   at Avalonia.AppBuilder.SetupUnsafe() in /_/src/Avalonia.Controls/AppBuilder.cs:line 303
   at Avalonia.AppBuilder.Setup() in /_/src/Avalonia.Controls/AppBuilder.cs:line 291
   at Avalonia.AppBuilder.SetupWithLifetime(IApplicationLifetime lifetime) in /_/src/Avalonia.Controls/AppBuilder.cs:line 199
   at Avalonia.ClassicDesktopStyleApplicationLifetimeExtensions.StartWithClassicDesktopLifetime(AppBuilder builder, String[] args, ShutdownMode shutdownMode) in /_/src/Avalonia.Controls/ApplicationLifetimes/ClassicDesktopStyleApplicationLifetime.cs:line 219
   at AvaloniaExample.Program.main(String[] argv) in /Users/h3/repos/Elmish.Avalonia/src/Samples/AvaloniaExample/Program.fs:line 20

Process finished with exit code 134.

This is my first try at this so I'm casting around for any help I can find. Thanks.

[houstonhaynes]

FWIW I'm on MacOS M1 on the latest version of Rider. (2023.1.3)

        <PackageReference Include="System.Reactive.Core" Version="5.0.0" />
        <PackageReference Include="CommunityToolkit.Mvvm" Version="8.2.0" />
        <PackageReference Include="Avalonia.Controls.DataGrid" Version="11.0.0-preview5" />
        <PackageReference Include="Avalonia.Desktop" Version="11.0.0-preview5" />
        <PackageReference Include="Avalonia.Diagnostics" Version="11.0.0-preview5" />
        <PackageReference Include="Avalonia.Themes.Fluent" Version="11.0.0-preview5" />
        <PackageReference Include="LiveChartsCore" Version="2.0.0-beta.801" />
        <PackageReference Include="LiveChartsCore.SkiaSharpView" Version="2.0.0-beta.801" />
        <PackageReference Include="LiveChartsCore.SkiaSharpView.Avalonia" Version="2.0.0-beta.800-11.0.0-rc1.1" />
        <ProjectReference Include="..\..\Elmish.Avalonia\Elmish.Avalonia.fsproj" />

[houstonhaynes]

Oh - and one more addendum - the LiveCharts2 sample app (C#) runs without issue using the same System, CommunityToolkit, Avalonia and LiveChartsCore versions

[JordanMarr]

It looks like the LiveCharts package you are using references a newer version of Avalonia (rc-1), so I had to updated the references to the latest:

    <ItemGroup>
        <PackageReference Include="System.Reactive.Core" Version="5.0.0" />
        <PackageReference Include="CommunityToolkit.Mvvm" Version="8.2.0" />
        <PackageReference Include="Avalonia.Controls.DataGrid" Version="11.0.0-rc1.1" />
        <PackageReference Include="Avalonia.Desktop" Version="11.0.0-rc1.1" />
        <PackageReference Include="Avalonia.Diagnostics" Version="11.0.0-rc1.1" />
        <PackageReference Include="Avalonia.Themes.Fluent" Version="11.0.0-rc1.1" />
        <PackageReference Include="LiveChartsCore" Version="2.0.0-beta.801" />
        <PackageReference Include="LiveChartsCore.SkiaSharpView" Version="2.0.0-beta.801" />
        <PackageReference Include="LiveChartsCore.SkiaSharpView.Avalonia" Version="2.0.0-beta.800-11.0.0-rc1.1" />
        <ProjectReference Include="..\..\Elmish.Avalonia\Elmish.Avalonia.fsproj" />
        <!--Condition below is needed to remove Avalonia.Diagnostics package from build output in Release configuration.-->
    </ItemGroup>

Next fix was that your MainViewModel.fs ShowChart was pointing to the wrong page/vm, so I fixed that as well:

let update (msg: Msg) (model: Model) = 
    match msg with
    | ShowCounter -> 
        { model with ContentVM = CounterViewModel.vm }  
    | ShowChart -> 
        { model with ContentVM = ChartViewModel.vm }
    | ShowAbout ->
        { model with ContentVM = AboutViewModel.vm }

Next was that upgrading all the packages seemed to break the DataGrid control used on the CounterView page, but that's a different problem for a different day, so I just commented out the DataGrid to bypass the error:

        <!--<DataGrid Items="{Binding Actions}" AutoGenerateColumns="True" Height="400">            
        </DataGrid>-->

That should get you beyond the build error so you can continue playing around with the chart page.

[JordanMarr]

Here are the rest of the steps:

• I had to explicitly give the chart width and height or else it wouldn't render at all:

<lvc:CartesianChart 
    Grid.Row="1" 
    MinHeight="300"
    MinWidth="600"
    Series="{Binding Series}">
</lvc:CartesianChart>

I added a Series binding with some static data just to see it render:

let series = 
    let lineSeries = LineSeries<int>(Values = [1 .. 10], Fill = null, Name = "Income") :> ISeries
    [|
        lineSeries
    |]

let bindings ()  : Binding<Model, Msg> list = [
    "Actions" |> Binding.oneWay (fun m -> m.Actions)
    "AddItem" |> Binding.cmd AddItem
    "RemoveItem" |> Binding.cmd RemoveItem
    "UpdateItem" |> Binding.cmd UpdateItem
    "ReplaceItem" |> Binding.cmd ReplaceItem
    "Series" |> Binding.oneWay (fun m -> series)
]

[JordanMarr]

What you were trying to do with the MVVM bindings... you can probably mix and match MVVM + Elmish, but I would be inclined to just use Elmish rather than mix paradigms.

I made sure this framework is updated to use the latest Elmish v4, so you should be able to use its new subscriptions feature to subscribe to the observable and push the new value into model.Series or something like that.

But if you really want to use MVVM, you will need to use a VM class with property members for the RelayCommands, not a module w/ let bindings.

[JordanMarr]

Sidestepping the whole observable thing (because I'm not sure what you need to do), here is a very simple version that adds random numbers:

ChartViewModel.fs

module AvaloniaExample.ViewModels.ChartViewModel

open System
open System.Collections.ObjectModel
open CommunityToolkit.Mvvm.Input
open Elmish.Avalonia
open LiveChartsCore
open LiveChartsCore.Defaults
open LiveChartsCore.SkiaSharpView

let _random = Random()

type Model = 
    {
        Data: int list
    }

type Msg = 
    | AddItem

let init() = 
    { 
        Data = []
    }

let update (msg: Msg) (model: Model) = 
    match msg with
    | AddItem ->
        { model with 
            Actions = model.Actions @ [ { Description = "AddItem" } ]            
            Data = model.Data @ [ _random.Next(0, 10) ]
        }

let bindings ()  : Binding<Model, Msg> list = [
    "AddItem" |> Binding.cmd AddItem
    "Series" |> Binding.oneWay (fun m -> 
        [|
            LineSeries<int>(Values = m.Data, Fill = null, Name = "Income") :> ISeries
        |]
    )
]

let designVM = ViewModel.designInstance (init()) (bindings())

let vm = ElmishViewModel(AvaloniaProgram.mkSimple init update bindings)

Make sure you update your Button Command binding to AddItem (not AddItemCommand) so it matches your binding:

<Button Margin="6" Command="{Binding AddItem}">Add</Button>

[houstonhaynes]

Thanks so much for all of this - quite an education - some of which I'm still absorbing. I have to admit that it was a little confusing to see an example with a "ViewModel" folder in what I thought would be an MVU structured project. So, for much of the time I was wondering if there was room in "Elmish" for MVVM.

So while I'm here - I've got to say that still confuses me a bit - why does the Elmish.Avalonia sample project have a "ViewModels" folder? What am I missing about this sample?

[FYI - my use of ObservableCollection was because It was in the LiveChart2 sample and I was modeling that code in F# (or that was the idea). I also use Observables so frequently with WildernessLabs Meadow it struck me as a mental hand-hold that I thought would be useful.]

[JordanMarr]

I guess it could be a misnomer to call them view models, but this is sort of as hybrid model that uses MVU to create a view model.

The observable is certainly doable, but maybe not worth the hassle unless you really need it.

[JordanMarr]

I should also add that you can have one big MVU loop if you want. I just prefer to have a localized MVU loop per view.

[houstonhaynes]

I agree 100% - the strongest reason for using the ObservableCollection was the "mechanical sympathy" with the C# example on the LiveCharts2 site - though they did mention that other methods were possible.

That opens up the can-o-worms on "just use functional" versus the constructor method - it's a cognitive burden thing - if a new user (like myself) can't determine what's just a convenience to the author versus what could otherwise be a more generalizable pattern... you get the point I'm sure - since you've been moving in and out of these frameworks for much longer. I've been reading "Stylish F#" and have been thinking about it as I go from app-level aping of other people's work to actually internalizing F# "intent" for the lack of a better term. (since "idiom" is in the eye of the beholder)

I like the idea of an MVU loop per view. I've also been thinking about breaking down the "code by folder" approach that's baked in to C#. I plan to blog about this at some point - more for notes for myself - but also for those who might be similarly unfamiliar with the variety of patterns out there - to help newbs like myself make sense of it as "conventions" emerge.

[houstonhaynes]

Sorry - spoke too soon - I'm still not seeing things work - same error.

How "picky" is this on MSBuild versions? I have three refs (.NET 6, 7, 8) and it (Rider on Mac) seems to want to use 8's MSBuild for some weird reason.

The good news - is that when I updated Avalonia.Themes.Fluent to rc1 the preview in Rider was rendering... 👍

[JordanMarr]

It looks like you skipped the first step (which happens to be the step that fixes your bug), which is to update the NuGet packages.
The Graph package you are using targets the newer release candidate version of Avalonia.
I posted all the NuGet packages above so you can just copy/paste them into your project file exactly I as I have them.

Also, you still need to rename your button command bindings to match the bindings in your VM.

[houstonhaynes]

Dang - thanks - I thought I had gotten all of them. Copy-paste it is!

[houstonhaynes]

Got it working - had to add Actions back to your one-pager. Really nice, tight layout. Fun! 🥇

module AvaloniaExample.ViewModels.ChartViewModel

open System
open Elmish.Avalonia
open LiveChartsCore
open LiveChartsCore.SkiaSharpView

let _random = Random()

type Model = 
    {
        Data: int list
        Actions: Action list
    }
    
and Action = 
    {
        Description: string
    }

type Msg = 
    | AddItem

let init() = 
    { 
        Data = []
        Actions = [ { Description = "Init" } ]
    }

let update (msg: Msg) (model: Model) = 
    match msg with
    | AddItem ->
        { model with 
            Actions = model.Actions @ [ { Description = "AddItem" } ]            
            Data = model.Data @ [ _random.Next(0, 10) ]
        }

let bindings ()  : Binding<Model, Msg> list = [
    "AddItem" |> Binding.cmd AddItem
    "Series" |> Binding.oneWay (fun m -> 
        [|
            LineSeries<int>(Values = m.Data, Fill = null, Name = "Income") :> ISeries
        |]
    )
]

let designVM = ViewModel.designInstance (init()) (bindings())

let vm = ElmishViewModel(AvaloniaProgram.mkSimple init update bindings)

[JordanMarr]

It does look very clean!

[houstonhaynes]

You'll be proud of me 😆

I switched over from ObservableCollection<ObservableValue> to <DateTimePoint> and managed to bind the XAxes definition without having to come up for air to ask you! 🦜 😁

The "odd" thing I ran into was that the add/remove/updates where "backward" and creating an odd behavior.

What I figured out after a hot minute ⏲️ was that I had initialized the series in ascending order (following the index value I used to create the DateTimeOffset) and the chart was dutifully re-ordering according to the XAxis. That meant when I RemoveAt[0] it was getting right of the last in the series visually (because of the DateTime order). I laughed pretty hard at myself when I finally figured out to switch from

for i from 0 .. 10 do

to

for i = 10 downto 0 do

then everything "just worked" 👍 🙄

Thanks again - I realize this was a pretty hefty investment on your part, but I hope to pay it forward by both writing about this in my yet-to-be-published blog - FSharpNotes and perhaps add a video or two to go with it as the project continues.

[JordanMarr]

Super cool! It looks really good with the labels.

Small thing, but this line:

let newSeries =

should probably be changed to a function so that it is always reinitialized when it is called from the init function:

let newSeries () =

[houstonhaynes]

THERE IT IS! I knew I had missed something.

BTW - I want to grab the toggleButton and set IsChecked <- false but "cheat" my way through with a simple

let toggleButton = parentControl.FindControl("AutoUpdate") :?> ToggleButton

I'm getting "lit up" but not really certain what the "parent control" actually means in the User Control context. Is it looking for an overall User Control "Name" reference? Why can't we just use a "this" value? (like - I'm looking here why don't you infer that?)

[daz10000]

I've been lurking here and enjoying the journey. If you're both up for it, this would be a great addition to the samples when its complete.

[houstonhaynes]

Thanks! I was wondering about building something that folks just "just build and run" without having to dig through the original project structure. Now that Elmish.Avalonia is available on nuget I think that's a big step forward.

I had also thought about fleshing out LiveChart2's sample app in this model - just as an exercise to create an F# equivalent. They have separated out some partial classes, which makes sense for their re-use in various examples from the same base visual - but I'm not sure that really suits the "garden path" metaphor I think would be useful to new folks here.

And I like the idea of an Elmish.Avalonia template as a first bookend for the garden path experience. Since this still an alpha I'm sure @JordanMarr already has his own ideas. 🧠 😁

[daz10000]

On Wed, Jun 28, 2023 at 04:45:50AM -0700, Houston Haynes wrote: Thanks! I was wondering about building something that folks just "just build and run" without having to dig through the original project structure. Now that Elmish.Avalonia is available on nuget I think that's a big step forward.

Not a strong push here, but my vote would still be keep it with the project code. I run into so many beautiful beautiful open source projects with minimal docs (which I totally understand, it's hard work to write / maintain docs), and often the docs aren't super helpful. A fully worked example is golden. Most productive coding is copying and hacking a working example. Once you're super familar with a library, then the template and an empty page is good, but the number of times I would have killed for just any example of X in a project (I filed a bug report recently on a feature in another library that I just couldn't get working after days and concluded was actually buggy - I couldn't find a single example anywhere on the internet or code base of it being used. Finally found another bug report, and then realized it had never worked. A single positive example with the code would have been an existence proof. Slightly more work for maintainer, but you can also build the demo projects with CI and they offer a smoke test that the library still works with "real code". I'll stop here, but I love the samples folder in a project..

[houstonhaynes]

I totally get that - I'm happy to post a PR. I'd love to get this button state management "feature" working - just to have that proof of concept of how to maintain UI sync with the actions dispatched in the code-behind. I think that would be a useful case for folks to see in F#.

[JordanMarr]

THERE IT IS! I knew I had missed something.

BTW - I want to grab the toggleButton and set IsChecked <- false but "cheat" my way through with a simple

let toggleButton = parentControl.FindControl("AutoUpdate") :?> ToggleButton

I'm getting "lit up" but not really certain what the "parent control" actually means in the User Control context. Is it looking for an overall User Control "Name" reference? Why can't we just use a "this" value? (like - I'm looking here why don't you infer that?)

You definitely want to avoid hacking the xaml control hierarchy in your MVU code. (If you have to resort to that, it would be better to do it in the code-behind file.)

If you are trying to enable/disable buttons that are bound to a command (Add, Remove, etc), you can use Binding.cmdIf:

"AddItem" |> Binding.cmdIf (fun m -> if m.Actions.Length > 5 then Some AddItem else None)

Alternatively, you could create a CanAddItem binding and manually bind it to the button:

<Button Margin="6" IsEnabled="{Binding CanAddItem}" Command="{Binding AddItem}">Add</Button>

    "AddItem" |> Binding.cmd AddItem
    "CanAddItem" |> Binding.oneWay (fun m -> m.Actions.Length > 5)

[houstonhaynes]

Thanks - I get your broader point - I spent a bit of time reading the Avalonia docs on code-behind for forms and my brain melted all over again. 🧠 Unfortunately I don't really grok how to tie that binding to the reset of the ToggleButton state itself.

So... I have in XAMAL

<ToggleButton Margin="6" IsChecked="{Binding IsAutoUpdateChecked}" Command="{Binding AutoUpdate}">AutoUpdate</ToggleButton>

and in bindings ()

   "IsAutoUpdateChecked" |> Binding.oneWay (fun m -> if not isAutoUpdating  then ToggleButton.IsChecked <- Nullable(false))

The thought here is that the "Reset" command is turning off the mutable isAutoUpdating boolean. For one - I'm getting an error on IsChecked not being static. For another - I'm not certain HOW this binding is used - it just seems more logical to set the state of the ToggleButton from the Reset itself.

The basic idea is that when the "Reset All" button is pressed - a new Series is generated and the isAutoUpdating is turned off. Am I thinking of this the wrong way? Instead of directly reaching out to control the button, should I be looking to tie the boolean state to the toggle button state so that isAutoUpdating = false always sets ToggleButton.IsChecked to Nullable(false)?

[JordanMarr]

It sounds like "IsAutoUpdateChecked" should be a two-way binding.
That way ticking the control in the UI will change it in your model, but you could also set it to false during your Reset command.

[houstonhaynes]

OK 💡 that's clearer - I'm just unsure how sending false to "IsChecked" via the binding is accomplished. The Reset command isn't binding aware.

What am I missing in this picture?

[houstonhaynes]

Is this what you're talking about?

When I click on "AutoUpdate" I get

Unhandled exception. System.Exception: TryGetMember FAILED: Property IsAutoUpdateChecked doesn't exist

but the ChartView has

<ToggleButton Margin="6" IsChecked="{Binding IsAutoUpdateChecked}" Command="{Binding AutoUpdate}">AutoUpdate</ToggleButton>

So I'm at a loss...

[houstonhaynes]

https://github.com/houstonhaynes/Elmish.Avalonia/blob/e28ddebd29c9f464e01cdca50246599b9d666d7f/src/Samples/AvaloniaExample/ViewModels/ChartViewModel.fs

[JordanMarr]

So first of all, drop the notion of using the ToggleButton Command. Instead, we will drive everything using a two-way binding to IsChecked:

<ToggleButton Name="AutoUpdate" Margin="6" IsChecked="{Binding IsAutoUpdateChecked}">AutoUpdate</ToggleButton>

On the MVU side, we can remove all the procedural WPF code and instead we want to focus on our abstraction.

Full code is listed at the bottom, but here is a breakdown:

• Added an IsAutoUpdateChecked field to the Model
• Replaced the AutoUpdate Msg with a SetIsAutoUpdateChecked Msg
• Added a two-way binding: "IsAutoUpdateChecked"
• Reset message now sets IsAutoUpdateChecked = false
• Reworked list of subscriptions to conditionally add or remove the "autoUpdateSubscription" based on the current model.IsAutoUpdateChecked field.

Here's the full code:

module AvaloniaExample.ViewModels.ChartViewModel

open System
open System.Collections.Generic
open System.Collections.ObjectModel
open Elmish.Avalonia
open Avalonia.Controls.Primitives
open LiveChartsCore
open LiveChartsCore.Kernel.Sketches
open LiveChartsCore.SkiaSharpView
open LiveChartsCore.Defaults

let _random = Random()

  
let newSeries (count: int option)  =
    let newCollection = ObservableCollection<DateTimePoint>()
    // use seriesCount to either 1) set a default 15 at init or 2) use the count passed in from the reset button
    let mutable seriesCount = 0
    match count with
    | None ->
        seriesCount <- 15
    | _ -> 
        seriesCount <- count.Value - 1
    for i = seriesCount downto 0 do
        // backdate the time in seconds by the index to create a series of points in the past
        let past = DateTimeOffset.Now.AddSeconds(-i).LocalDateTime
        let _randomNull = _random.Next(0, 99)
        // in 1% of cases produce a null value to show an "empty" spot in the series
        match _randomNull with
            | i when i = 0 ->
                newCollection.Add(DateTimePoint(past, System.Nullable()))
            | _ -> newCollection.Add(DateTimePoint(past, _random.Next(0, 10)))
    newCollection
    
let XAxes : IEnumerable<ICartesianAxis> =
    [| Axis (
            Labeler = (fun value -> DateTime(int64 value).ToString("HH:mm:ss")),
            LabelsRotation = 15,
            UnitWidth = float(TimeSpan.FromSeconds(1).Ticks),
            MinStep = float(TimeSpan.FromSeconds(1).Ticks)
        )
    |]

type Model = 
    {
        Series: ObservableCollection<ISeries>
        Actions: Action list
        IsAutoUpdateChecked: bool
    }
    
and Action = 
    {
        Description: string
    }

type Msg = 
    | AddItem
    | AddNull
    | RemoveItem
    | UpdateItem
    | ReplaceItem
    | Reset
    | SetIsAutoUpdateChecked of bool

let init () =
    {
        Series = 
            ObservableCollection<ISeries> 
                [ 
                    LineSeries<DateTimePoint>(Values = newSeries(None), Fill = null, Name = "Luck By Second") :> ISeries 
                ]
        Actions = [ { Description = "Initialized"} ]
        IsAutoUpdateChecked = false
    }
    
let update (msg: Msg) (model: Model) =
    let values = model.Series[0].Values :?> ObservableCollection<DateTimePoint>
    match msg with
    | AddItem ->
        values.Insert(values.Count, (DateTimePoint(DateTime.Now, _random.Next(0, 10))))
        { model with 
            Actions = model.Actions @ [ { Description = "AddItem" } ]    
        }
    | AddNull ->
        values.Insert(values.Count, (DateTimePoint(DateTime.Now, System.Nullable())))
        { model with 
            Actions = model.Actions @ [ { Description = "AddNull" } ]    
        }
    | RemoveItem ->
        values.RemoveAt(0)
        { model with 
            Actions = model.Actions @ [ { Description = "RemoveItem" } ]    
        }
    | UpdateItem ->
        let item = _random.Next(0, values.Count - 1)
        let fstValueTime = values.[item].DateTime
        values[item] <- DateTimePoint(fstValueTime, _random.Next(0, 10))
        { model with 
            Actions = model.Actions @ [ { Description = "UpdateItem" } ]            
        }
    | ReplaceItem ->
        let lastValueTime = values[values.Count - 1].DateTime
        values[values.Count - 1] <- DateTimePoint(lastValueTime, _random.Next(0, 10))
        { model with 
            Actions = model.Actions @ [ { Description = "ReplaceItem" } ]            
        }
    | Reset ->
        // pass up the current length of the series to the newSeries function
        model.Series[0].Values <- newSeries(Some values.Count)
        { model with 
            IsAutoUpdateChecked = false
            Actions = model.Actions @ [ { Description = "Reset" } ]
        }
    | SetIsAutoUpdateChecked isChecked ->
        { model with 
            IsAutoUpdateChecked = isChecked
            Actions = model.Actions @ [ { Description = $"IsAutoUpdateChecked: {isChecked}" } ]
        }

let bindings ()  : Binding<Model, Msg> list = [
    "Actions" |> Binding.oneWay (fun m -> m.Actions)
    "AddItem" |> Binding.cmd AddItem
    "RemoveItem" |> Binding.cmd RemoveItem
    "UpdateItem" |> Binding.cmd UpdateItem
    "ReplaceItem" |> Binding.cmd ReplaceItem
    "Reset" |> Binding.cmd Reset
    "IsAutoUpdateChecked" |> Binding.twoWay ((fun m -> m.IsAutoUpdateChecked), SetIsAutoUpdateChecked)
    "Series" |> Binding.oneWayLazy ((fun m -> m.Series), (fun _ _ -> true), id)
    "XAxes" |> Binding.oneWayLazy ((fun _ -> XAxes), (fun _ _ -> true), id)
]

let designVM = ViewModel.designInstance (init()) (bindings())

open Elmish
open System.Timers

let subscriptions (model: Model) : Sub<Msg> =

    let autoUpdateSubscription (dispatch: Msg -> unit) = 
        let timer = new Timer(1000) 
        let disposable = 
            timer.Elapsed.Subscribe(fun _ -> 
                let _randomNull = _random.Next(0, 99)
                match _randomNull with
                | i when i = 0 ->
                    dispatch AddNull
                | _ -> dispatch AddItem
                dispatch RemoveItem
            )
        timer.Start()
        disposable

    [
        if model.IsAutoUpdateChecked then
            [ nameof autoUpdateSubscription ], autoUpdateSubscription
    ]

let vm = ElmishViewModel(
    AvaloniaProgram.mkSimple init update bindings
    |> AvaloniaProgram.withSubscription subscriptions
)

[houstonhaynes]

I was part-way there on my own but would have never grokked Binding.twoWay without struggling with this for a minute or three. Thanks again.

[daz10000]

On Wed, Jun 28, 2023 at 04:14:51PM -0700, Jordan Marr wrote: So first of all, drop the notion of using the `ToggleButton` `Command`. Instead, we will drive everything using a two-way binding to `IsChecked`: ```xaml <ToggleButton Name="AutoUpdate" Margin="6" IsChecked="{Binding IsAutoUpdateChecked}">AutoUpdate</ToggleButton> ```

This is one of my favorite features in the the library Jordan - being able to manage all of that fiddly UI state simply by connecting a property to a model variable is just the way it should be

[houstonhaynes]

Agreed. 💯 That's why I really wanted to get this "orthogonal" case baked into my brain. I think it's easy to "fall back on old habits" and while it was a bit of a struggle it's really worth it. This exercise opens many doors.

[JordanMarr]

The syntax on the two way binding is not very intuitive. I had to look up an example on the Elmish.WPF repo.

Also, the new Elmish v4 subscription system is extremely unintuitive. I have to look at examples every time to get it right, even though I did the upgrade from v3 to v4 on the Elmish.WPF repo.
It is, however, very solid and well built!

[houstonhaynes]

I don't mind unintuitive - I think that's a form of cognitive burden that frameworks like these should put on the user/developer as the cost of doing business with fewer lines of code.

[JordanMarr]

It looks like the DataGrid Items property changed to ItemsSource.

[houstonhaynes]

Yeah I updated it in my PR for the Example app - not sure where else it should be tweaked

(I started a new discussion thread about it) 👍

[JordanMarr]

Oh, you already figured this out?

[JordanMarr]

Ok, I just realized you created a PR and already fixed that.

[houstonhaynes]

FWIW - I tried to add the "Ok" button to the bottom of the ChartView so that it would also return to the CounterView like About (showing the global being used in more than one place) and it REALLY started lighting up the model in a way that made it a mess for me to deal with. I'll eventually jump back in and unpack that as a "learning opportunity" but for now I have to turn my attention back to WildernessLabs Meadow.

[JordanMarr]

Oh really? I would have imagined that you could simply disable the auto update and then send the message to transfer back to the main page.

[houstonhaynes]

Well I was just trying ape what was in the About page model - again - not really understanding where the easier paths may be - that's where I usually start (trying to paint like the masters) 🎨

[JordanMarr]

For the chart page, the Ok button implementation will be slightly different since you are using the "simple" Elmish setup.

open Messaging

| Ok ->
        bus.OnNext(GlobalMsg.GoHome)
        { model with IsAutoUpdateChecked = false }

That's it!

[houstonhaynes]

Ohhhh I see it now! I got a bit wrapped around the OTHER bits...

I'm curious about [in AboutViewModel.fs]...

model, Cmd.OfFunc.perform sendMessage () MsgSent

Why does that need to be a full loop where the bit you just offered up does not? Am I reading that right? The Msg of MsgSent of unit is more-or-less a placeholder for the return of that command? Why is it needed there but not in what you provided for ChartViewModel?

[JordanMarr]

The purpose of using the non-simple version of the Elmish loop (with Cmd) is so that you can safely incorporate side-effects into your loop in a declarative way.
In the Chart VM, it looks a lot more simple, but now update is no longer a pure function which can affect testing.

Using Cmd.of___ to trigger side effects means that you can pass that Msg in a test and it won't actually do the side-effect; it will just return a declarative Cmd saying that it's going to do it, which you can test for.

As for why Elmish requires a follow-up Msg to be specified for Cmd.ofFunc, I don't know, but it does.

[houstonhaynes]

Thanks for that. I'd l Iike to unpack that.

On the surface (pun!) I'm not as concerned about functional purity in a UI loop. But I'm interested in learning the MVU model to fully grok it - and I'm willing to update (pun2!) my thinking on layer isolation this close to the mutable world. (I'm on a roll) 🤣 And if there's a V2 of that OK button operation I'm up for a v1.2 at some point.

I must confess that I felt guilty about not writing tests for the code that I splashed onto the page. That was the only reason why I had any hesitancy about including it in the examples because I haven't put any tests to go with it. Old habits die hard, even the good ones.

It might be a good thing to build tests as a proof - which might be my next sidebar. Thanks again.

[JordanMarr]

I don’t write tests a lot. 😆
Generally, I only test when an update msg handler has some extra conditional logic that could have many different results. But in this case where I feel it could be useful, MVU makes it so easy to do so by right of being a pure function.

[houstonhaynes]

I dig that sentiment. In fact I've been nibbling around the edges of a presentation on how many classes of unit tests can be thought of as compiler customization. And by extension, how layered code base eventually emerges as its own DSL, if well-managed. I was a director of app modernization at a DevSecOps shop and most of my days were spent giving speeches to people how DevSecOps was really a compilation extension for the larger system (which is why it has to be locked down - made safe - and thought of as a whole, not a cafeteria-style personal choice). People kept telling me "you should do a talk on that" and well - it's still on a side burner... 😉

And to that point - one of the first concepts that really grabbed me about F# was how type and DU structure can be a form of compiler instruction that can eliminate swaths of tests. I don't think that the community talks about it enough. And it makes sense, because as soon as it becomes "the new normal" it folds into the general sense of being more productive for the same amount of think time. But I digress...

That's a long way of saying that I'd like to get my head wrapped around this for more than one reason. 😄

[JordanMarr]

I don't know how I missed this before (because I definitely looked for it), but I found a better way to call the message bus using Cmd.ofEffect (instead of using Cmd.OfFunc.perform + a follow-up 'Msg):

AboutViewModel.fs

module AvaloniaExample.ViewModels.AboutViewModel

open Elmish.Avalonia
open Elmish
open Messaging

type Model = 
    {
        Version: string
    }

type Msg = 
    | Ok

let init() = 
    { 
        Version = "1.1"
    }, Cmd.none

let update (msg: Msg) (model: Model) = 
    match msg with
    | Ok -> 
        model, Cmd.ofEffect (fun _ -> bus.OnNext(GlobalMsg.GoHome))

let bindings ()  : Binding<Model, Msg> list = [
    "Version" |> Binding.oneWay (fun m -> m.Version)
    "Ok" |> Binding.cmd Ok
]

let designVM = ViewModel.designInstance (fst (init())) (bindings())

let vm = ElmishViewModel(AvaloniaProgram.mkProgram init update bindings)

[houstonhaynes]

That's really interesting! It's definitely time for me to check into the nuance of those commands. Lots to glean!

[houstonhaynes]

Right now, I'm camping - just spotty 4G LTE service at the foot of Mt. Mitchell. ⛰️🏕 I was hoping to have enough 📶 to noodle around a bit, but restoring is a no-go. 👎 Bummer.

When I'm back in the saddle (and on high-speed residential 5G) I'll make some updates. Ive been toying with the idea of extending the classic Mandelbrot sample to run on GPU. 😏