Elmish.wpf: F# XAML projects?

[cmeeren]

With the release of .NET Core 3.0, it seems the XAML designer works for normal F# projects. So I'm currently experimenting with converting the samples to pure F#.

This has impacts for #93.

[cmeeren]

Abandoning this for now (anyone is welcome to experiment further).

F#'s lack of partial classes means that code-behind files aren't supported. I have managed to get SingleCounter to compile and run by using FsXaml and adding the following to the fsproj file (no deep insights, just testing stuff to see what works):

<Compile Include="Program.fs" />  <!-- existing line to show where this goes -->
<Page Remove="*.xaml" />
<Resource Include="*.xaml" />

Without those lines, the project won't compile.

However, the EventBindingsAndBehaviors sample is giving me trouble even with the "workaround" above. FsXaml fails at runtime with errors I couldn't get to the bottom of.

I recommend sticking to C# XAML projects for now.

[BentTranberg]

I had to leave FsXaml behind some years ago because there's an issue involing it and XAML generated by DevExpress WPF components. According to Reed Copsey the problem wasn't with FsXaml, but with DevExpress not following specs. FsXaml isn't BAMLing like C#, and the BAMLer was more forgiving - and is of course what DevExpress and everybody relates to. So whatever the cause, I felt much safer staying on the wide path to avoid trouble. Even RC himself suggested I should just use C# for XAML to solve my issues (there was more than that one), while indicating something to the effect that FsXaml was not the way forward. He was developing Gjallarhorn at the time, and I was torn between Gjallarhorn and Elmish.WPF. I still think Gjallarhorn is interesting, but it seems Elmish is more favored, and I use it in Bolero also, so again taking the widest path with Elmish.WPF.

I too recommend sticking to C# XAML projects as the de facto standard for now - and until we have enough experience with the new stuff coming. Of course I do want to move everything I have to .NET Core, it would be lovely to have everything in F# projects, and most of all I want to have every project in the new project format. But it has to work, work well, and have backing from MS and the community before I dare trust my business to it. Until then I know what I've got is rock solid, and there's really not much of a downside now that I've got it in place.

[TysonMN]

Link to Gjallarhorn:
https://github.com/ReedCopsey/Gjallarhorn

[TysonMN]

Like most GUI frameworks, Elmish.WPF uses "magic" strings to bridge the gap between F# and XAML. The binding names to be specific. In addition to getting the binding names wrongs, another thing that can fail at runtime is getting the data type wrong. For example, in the SingleCounter sample, deleting float from...
https://github.com/elmish/Elmish.WPF/blob/66a6b49978c10f3a9c40c479ca8957517acba0ff/src/Samples/SingleCounter/Program.fs#L32-L34
...causes an exception to be thrown when moving the Slider.

F# type providers help with this creating an F# type from some non-F# source. For example, I am using the JSON type provider to read a JSON configuration file.

According to my limited understand of FsXaml, it is an F# type provider for XAML. Even with the XAML files in a C# project, I think we should be able to use FsXaml's XAML type provider to ensure our binding names and types are correct at compile time (instead of runtime).

Is that true? Can Elmish.WPF be made more type safe by using the XAML type provider in FsXaml?

[cmeeren]

I'm not sure FsXaml can do that, but I have very limited experience with FsXaml. The only thing I know FsXaml does, in addition to creating the actual type, is giving you access to named XAML elements.

Feel free to experiment.

[BentTranberg]

Another project that can possibly be of interest in relation to this, is https://github.com/dmitry-a-morozov/fsharp-wpf-mvc-series

It's been a long time since I played around with Gjallarhorn and F# MVC, so I don't remember much, but I think at least there was discussions revolving around this particular theme - how to bind more dependably than with just magic strings. Perhaps Morozov explains something about that in his documentation, which I remember was a step by step guide on how he built the thing.

As for type providers - I try to stay away from them as much as possible, and I'm not the only one that is skeptical based on experience. All I've seen have issues, though a very few does work well enough. I only use one at this time, and that's Bolero, which is stable, but sometimes require restarting VS to get in sync with the html files. If you introduce a type provider in Elmish.WPF, then perhaps consider make it optional in some way if it isn't too much of a bother. E.g. make it possible to bind with either magic string or through the type provider, so that if the type provider fails, at least the magic string mechanism saves the day.

[cmeeren]

The discussion of a TP is interesting, feel free to keep it going! 👍 But I suggest taking it to a separate correctly scoped issue, since issue this is about placing XAML files in F# projects.