Changed/extended SubModelSelectedItem sample

[YkTru]

This PR is a significant modification of the "SubModelSelectedItem" sample, demonstrating how to create a basic form designer using pattern matching for different components/submodels. It also outlines how to implement a DataTemplateSelector. ( [edit] might not be needed )

However, the primary goal in the near future is to convert all the "old-style" bindings to static bindings.

What do you think?

[YkTru]

@marner2:
Whenever you have time, could you please update the "old-style" bindings in the PR sample to an entirely newer/modern static bindings style? (also, if I understood well, you were looking to eventually revise the static bindings approach/strategy/helpers?

"In fact, I'm tempted to remove the model ones as you can always introduce it with a call to Bindings.mapMsgWithModel and just disregard the original msg (which is the obj parameter).
I'll try to look at that in more detail in the next few weeks, as I have time."

Thank you

[Evangelink]

Hi @YkTru,

I am sadly no longer doing WPF or F# and the issue is quite old so I don't recall the details.

[YkTru]

Got it!! (I think)

Please @TysonMN and @marner2, could you look at the sample and decide if it should be revised then pushed/made as a new separate sample? (sorry for the bad code formatting, I'm having trouble using Fantomas).

I know some parts were done quick and dirty and should be revised/refactored (eg: I don't handle ComboBox item selection = error), but everything seems to work perfecly.

(also note @TysonMN that I didn't use DataTemplateSelector as you advised, but ain't using IViewModel, ViewModelArgs and CurrentModel directly a hack/not recommended? )
This is the key part:

[<AllowNullLiteral>]
type FormComponent_VM(args: ViewModelArgs<App.Model * App.FormComponent, App.Msg>) =
    inherit ViewModelBase<App.Model * App.FormComponent, App.Msg>(args)

    member this.CurrentModel =
        (this :> IViewModel<App.Model * App.FormComponent, App.Msg>)
            .CurrentModel

    member this.Model = fst this.CurrentModel
    member this.FormComponent = snd this.CurrentModel

    member this.Id =
        match this.FormComponent with
        | App.FormComponent.TextBox tb -> tb.Id
        | App.FormComponent.CheckBox cb -> cb.Id
        | App.FormComponent.ComboBox cb -> cb.Id

    member this.ComponentVM: obj =
        let id = this.Id

        match this.FormComponent with
        | App.FormComponent.TextBox tb ->
            upcast TextBox_VM(ViewModelArgs.map (fun _ -> tb) (fun msg -> App.Msg.TextBox_Msg(id, msg)) args)
        | App.FormComponent.CheckBox cb ->
            upcast CheckBox_VM(ViewModelArgs.map (fun _ -> cb) (fun msg -> App.Msg.CheckBox_Msg(id, msg)) args)
        | App.FormComponent.ComboBox cb ->
            upcast ComboBox_VM(ViewModelArgs.map (fun _ -> cb) (fun msg -> App.Msg.ComboBox_Msg(id, msg)) args)

---

Do you think I should add :

• Undo/redo
• An property grid panel (where I can set the FormComponent properties)
• Serialization
• Comments to explain some parts

?

[YkTru]

@xperiandri, do you think accessing directly IViewModel, ViewModelArgs and CurrentModel is a hack/not recommended? Do you see a more "Elmish.WPF" way I could get the same behaviors? Do you see any other drawbacks?

[<AllowNullLiteral>]
type FormComponent_VM(args: ViewModelArgs<App.Model * App.FormComponent, App.Msg>) =
    inherit ViewModelBase<App.Model * App.FormComponent, App.Msg>(args)

    member this.CurrentModel =
        (this :> IViewModel<App.Model * App.FormComponent, App.Msg>)
            .CurrentModel

    member this.Model = fst this.CurrentModel
    member this.FormComponent = snd this.CurrentModel

    member this.Id =
        match this.FormComponent with
        | App.FormComponent.TextBox tb -> tb.Id
        | App.FormComponent.CheckBox cb -> cb.Id
        | App.FormComponent.ComboBox cb -> cb.Id

    member this.ComponentVM: obj =
        let id = this.Id

        match this.FormComponent with
        | App.FormComponent.TextBox tb ->
            upcast TextBox_VM(ViewModelArgs.map (fun _ -> tb) (fun msg -> App.Msg.TextBox_Msg(id, msg)) args)
        | App.FormComponent.CheckBox cb ->
            upcast CheckBox_VM(ViewModelArgs.map (fun _ -> cb) (fun msg -> App.Msg.CheckBox_Msg(id, msg)) args)
        | App.FormComponent.ComboBox cb ->
            upcast ComboBox_VM(ViewModelArgs.map (fun _ -> cb) (fun msg -> App.Msg.ComboBox_Msg(id, msg)) args)

[xperiandri]

I think it is the right way to go. I do the same

[YkTru]

To @TysonMN and @marner2,

Hi guys, I don’t mean to insist or add any pressure, but I want to understand please: it’s been nearly 3 weeks since I shared this modified sample proposal, and I've noticed that many interactions/discussions/questions (from both myself and other users) have remained unanswered or pending over the last 4-5 months.

I fully understand that you're not paid for this work, and I'm deeply grateful for the contributions you've made to the community. I also realize that time or interest might be limited. However, it’s a bit disheartening to put forth ideas and proposals, hoping to contribute, only to feel stuck in limbo without feedback.

@TysonMN, I’ve followed your helpful insights in various issues and PRs over the years, and I’m truly impressed by your generosity. That said, it’s difficult not to feel discouraged when I submit a sample building on your own work and receive no feedback. Am I interacting the wrong way?

---

As it stands, I can’t confidently revise the modifications I’ve made, as I’m unsure if my approach to accessing CurrentModel is sound practice (and I’ve also run into some strange binding bugs when trying to create a Property Editor). This uncertainty makes it hard for me to move forward with implementing other features like UndoRedo, Serialization, or even eventually achieving fully static bindings.

A (larger) sample showcasing these capabilities, in my opinion, would really highlight many feature of Elmish.WPF and could benefit the community. (And I know that many users have asked for such a “larger” sample over the years).

I’m definitely committed, but when it comes to this library, I often feel a bit overwhelmed, limited or confused on the best practices.

---

So, I’m wondering: is it still worthwhile to actively contribute to the project, or is the community slowing down, or perhaps even declining? Alternatively, is there a better time of year for asking questions or submitting proposals? I’d prefer not to hold onto hope indefinitely, unsure whether my contributions are relevant, uninteresting, or poor practice, or if I should follow up at a more suitable time.

Again, I don’t mean to come across as rude or ungrateful, and I truly don’t enjoy writing this type of message, but this situation has affected my confidence in using the library and, from reading through the issues, it seems that others have faced similar experiences over the years.

Thank you again for all your work, and I hope you have a great day!

[TysonMN]

@YkTru, I sent you an email. Did you receive it?

[marner2]

@YkTru I can answer one part of the issue for my part:

Alternatively, is there a better time of year for asking questions or submitting proposals?

I was actively managing this repository up until the end of last year, and the new year brought a change in the projects I was working on. I've had to pause a lot of my contributions over the past few months, and essentially let the backlog "back up" over the summer. I do plan on resuming more regular work on the project over the fall and winter once some of my other projects wind down (they're already becoming less intense, but not to the point yet that I can invest significant time/effort here). I want to get the static VM stuff out to a more "fleshed out" solution. I do believe it's fully functional (we had full static view models on a large project with quite a few screens and dozens of controls using the current version, and we had working asynchronous model updates), but there seems to be a gap with the examples and documentation for that (as well as some confusing designs that came from starting it as a drop-in replacement of the dynamic stringly-typed bindings). Additionally we had Elmish upgrade some of its interfaces with its latest version that needed to be incorporated, as well as highly relevant F# language upgrades, right over this time period.

I appreciate the feedback. At this point, the more feedback I have once I restart effort on it in the next few months, the more efficiently I'll be able to work.

[YkTru]

@marner2 Excellent! Thank you for the update, and regarding upcoming future investment from you in fall/winter, I feel very reassured and excited. I will try to manage on my own until then and might have a few more specific questions/suggestions to share when you have time.

It's quite intriguing, and I'm looking forward to seeing the developments to come!

I want to get the static VM stuff out to a more "fleshed out" solution

I’d be happy to help with my 'beginner’s/intermediate mind' by pointing out where I, coming directly from C#/WPF, personally found things +/- unclear

but there seems to be a gap with the examples and documentation for that

Glad to hear! I'll make sure to gather and share as concisely as I can any insights or suggestions:

I appreciate the feedback. At this point, the more feedback I have once I restart effort on it in the next few months, the more efficiently I'll be able to work.

Thank you again for your generosity!