Best way to implement "Statically-typed view model" approach?

[YkTru]

I'm having trouble understanding how to implement the statically-typed view model approach. (everything is working fine with the bindings approach)

I attempted to use the guidance from Elmish.WPF on GitHub, but despite spending a lot of time on it, I find the documentation either unclear or possibly outdated. Is there a complete and current sample that demonstrates the best way to do this?

I've been working on this implementation, but regardless of my efforts, the 'HelloViewModel' does not appear in Intellisense. Here's my attempt: https://github.com/YkTru/ElmishWPF_StaticallyTypedViewModel.

Any assistance would be greatly appreciated. Thank you.

[YkTru]

@TysonMN @marner2

I'm sorry to bother you, but am I doing anything wrong? Thank you.

[marner2]

Ahh, I see what the problem is. Yes, your View Model cannot be inside a module, as XAML doesn't support nested types (F# modules are implemented as types in .NET). This slightly complicates your simple example, as you'll have to split things up into several modules.

Take your view model and put it outside and after the zApp module, then put the main function inside another module after the view model. You'll also need to move the Elmish.WPF open under the namespace.

I'll work on making the documentation clearer with an explicit section in the docs around this feature.

The example of this is in SubModelStatic.Core. It's a bit more involved as I wanted to illustrate how you get nested auto-completions in the wpf xaml designer if you use this method.

Let me know if you have any more questions or suggestions!

[YkTru]

It works, thanks a lot!

1. I've created a new sample with more relevant State/Msg; do you want me to share it so you can review it, and then maybe add it to the Elmish.WPF samples?

I must mention, as a newcomer transitioning directly from C#+MVVM, such a sample would have saved me a great deal of time and effort. (I guess from the documentation any F# programmer would have figured it out rapidly, but for anyone in a learning process I think it might no be as evident)

---

2. Do you personally recommend/prefer the bindings approach or the statically-typed VM one? I obviously lean towards the bindings approach for readability, but I assume that typed XAML bindings are way more advantageous than those based on strings?

I'm asking since in the samples, clearly the bindings approach is preferred, so does it have any advantages versus the other one other than readability and a more "functionnal" style?

Thank you again

[LyndonGingerich]

@YkTru

If you have a sample to suggest already made, by all means share it. Even if we don't use it directly, it could inspire ideas.

The "view model class" approach is relatively new, which is why the "binding list" approach has many more samples. If you use view model classes, you will be able to navigate from XAML binding usages to their definitions in Rider and Visual Studio. Rider will also check XAML when you search for usages. I don't think that the "binding list" approach has any particular advantages, but we will keep it around to avoid breaking existing code.

[TysonMN]

Do you personally recommend/prefer the bindings approach or the statically-typed VM one? I obviously lean towards the bindings approach for readability, but I assume that typed XAML bindings are way more advantageous than those based on strings?

(We having been calling them dynamic bindings and static bindings.)

I prefer dynamic bindings, but I stopped using Elmish.WPF (due to job change) before static bindings were created.