Proposal: Better F# support

[jesbis]

Proposal: Better F# support

Summary

F# is a popular functional-style programming language that has default support in Visual Studio for .NET console apps and libraries, but not for UI apps. With WinUI 3.0 we have an opportunity to enable first-class support for F# in Xaml apps.

Rationale

Better F# support was noted as a good opportunity to improve WinUI in the 3.0 roadmap discussion issue.

This would enable Xaml apps to use F# where most appropriate, e.g. for business logic to benefit from F#'s concision, testability, type system and correctness guarantees.

Scope

Capability	Priority
Enable using F# for app business logic	Must
Enable using Visual Studio F# tools with Xaml apps	Must
Provide F# samples	Should
Enable using F# for Xaml page codebehind partial classes	Could
Enable mixing and matching languages (e.g. F# for data and logic, C# for UI + bindings)	Could
Provide F# project templates	Could

Important Notes

Open Questions

1. Is existing xlang support sufficient (with new samples)?

2. What types of templates or samples would be useful?

3. Should this include supporting Xaml page codebehind files?

4. Could/should this include mixing languages in a project?

[mdtauk]

Duplicate of #736

[jesbis]

Duplicate of #736

That's a PR to add it to the roadmap doc - we'd like to have an issue to track this as well 😊

[mdtauk]

@jesbis Fair enough. The more F# the better. Keep people happy, and ensures WinUI 3.0 encompasses as much of Microsoft dev platforms as possible. 😀

[TonyHenrique]

F# I see two important approaches:

1. Make the F# (mutable) Records XAML Binding Friendly / Gjallarhorn;

2. Elmish style

Both could be supported, and have samples. Maybe on future only 1 trend become more used.

We will need the F# Project Templates for UI on the .NET 5

[mdtauk]

It would be great to mix and match F# and C# in a single project. Use F# for data stuff, and C# for UI/Commanding.

[TonyHenrique]

F# only + GUI should work perfectly, standalone.
A F# only solution would be compatible for example, with consuming an Record from Azure Function + F# and Bind it TwoWay to a TextBox, for example.

A UI/Commanding in F# would look very simple and cool!

[charlesroddie]

@jesbis

1. Enable using F# for app business logic | Must
2. Enable mixing and matching languages (e.g. F# for data and logic, C# for UI + bindings) | Could

These seem the same, and are implied by allowing C# projects referencing WinUI to also reference any .Net projects. That should be a given (assuming that you can access WinUI by installing a nuget package).

(But if 5. means mixing and matching languages within the same project, that's not possible because of ordering differences between C# and F#.)

2. Enable using Visual Studio F# tools with Xaml apps | Must

Can you clarify this? "Xaml" is very confusing at the moment. If "Xaml" means the markup language, then it's a complex issue possibly to be solved with a type provider (see link below). But if "Xaml apps" means "WinUI apps" then this is just part of 1.

4. Enable using F# for Xaml page codebehind partial classes | Could

See discussion of partial classes/XAML type providers/BAML compilation here: dotnet/wpf#162 .

[JaggerJo]

Currently it is not possible to build UWP UIs in F#. By shipping the whole UI Layer (as planned in Win UI 3.0) this will at least be possible, and I'm impatiently looking forward to it.

1: Is existing xlang support sufficient (with new samples)?
Personally ok with that, basic templates would be nice.

2: What types of templates or samples would be useful?
Basic samples would be a nice starting point.

3: Should this include supporting Xaml page codebehind files?
I think a lot of F# Developers would prefer a MVU approach for building UIs.
Typical XAML + MVVM relies on mutability, something like Fabolous specific for UWP would be a huge selling point (in my opinion).
Basically Elm / React like MVU abstractions to be more general.

4: Could/should this include mixing languages in a project?
Can imagine this to get messy. F# depends on file order.

[cartermp]

Something I'll note is that supporting .NET Core completely implies supporting F#. So if a goal is, e.g., supporting .NET Core 3.0, then F# support comes with that. However this does not imply a level of tooling support, such as designers.

[TonyHenrique]

If the F# (mutable) Records XAML were Binding Friendly and we had some example, with UI Commands included, I think that the Designer would work with the same tooling from C#, and we would have the "code behind" + Data objects in F#.

For example: How to do a WinUI GUI of a Invoice screen that has Customer, Invoice, Invoice Items. With buttons New Invoice, select customer, Add / Remove Invoice Items.

How to model it in F# and Bind the Data to the UI, and Bind the Button commands to F# functions ?

[charlesroddie]

@TonyHenrique The native binding approach in .Net UIs (WPF/UWP/Xamarin/Avalonia) has severe weaknesses: complete lack of type safety, hacky implementation of maps ("converters"), magic strings everywhere. Not a good fit for F#. It is better to ignore this infrastructure and use either moderate functional approaches (reactive approaches such as Gjallarhorn - you might see these as properly done implementations of binding) or extreme functional approaches (Elmish, e.g. Fabulous).

Better to use xaml purely for design and have a type provider give access to the UI objects (as in FsXaml for WPF).

[TonyHenrique]

A WinUI XAML F# type provider would be a cool approach to separate the UI code from the events and data binding code.

Doing this, we will be able to use the regular WinUI XAML Design Time editor.

(What worries me in elmish is that for large, complex UI, mixed inside the code, It tends to look like old php spaghetti code.
Gjallarhorn is also nice. It is up to the F# team to choose for the best for us)

Now, please release it with a proper UI/code separation sample, having the WinUI .xaml file and a .fs file with, like I said, a Window with 3 level items: customer, invoice, invoice items and add/remove items buttons, for example.

I think that with this and the Azure Functions F# Project Template it will be easy to switch completely to F# on my new projects.

[TonyHenrique]

Another thing that could be done is to allow XAML literals in C#/F# code.
This would enable code like this

let myButton title = <Button Text=title />

and it would look familiar for XAML fans like me, and also looks like React code.

[Happypig375]

No thanks, I'm satisfied with the Fabulous/Fable way of declaring views.

[isaacabraham]

@TonyHenrique I disagree. It's not up to MS to decide how we should develop UIs in F#. There's room enough for several approaches, although I personally prefer the Elmish style because it takes full advantage of F# rather than having to mess around with mutable data structures everywhere.

[TonyHenrique]

@isaacabraham Is it possible to use Elmish MVU, with a WinUI XAML Type Provider, and having a the UI declaration in a separate XAML file ? This would allow to use the regular XAML editor, but having the immutability and type safety of F#.

About MS deciding this, there are many advantages. Having a proper F# GUI Visual Studio Project template for the selected way (whether: binding mutable records, gjallahorn, or elmish with separate XAML file) would be awesome.
I would be very interested in seeing this.

[isaacabraham]

I can't comment on WinUI but we have WPF apps in a pure F# solution that use the built-in VS XAML designer + the XAML Type Provider. We used FSharp.ViewModule although we'd probably today use the Elmish WPF library.

Regarding templates, I have mixed feelings about them. Firstly, whilst they are useful as a tool to raise marketing and awareness, they are difficult to change and inflexible. A better solution IMHO would be a dotnet template and / or nuget package - something more code focused rather than being coupled into VS - we've moved on (or should be moving away) from that IMHO.

This also comes right back to whether this is a "MS" decision or something that is community led or not. Rather than relying on MS to decide what this looks like, why not be proactive and create something without waiting / relying on someone else.

[kathyang]

Thank you @mdtauk @TonyHenrique @charlesroddie @JaggerJo @cartermp @Happypig375 @isaacabraham and others for your thoughtful comments on this issue! I am helping the UWP Xaml team to determine if and how to invest in F# support. What kind(s) of support would be most helpful when creating F# apps?

[TonyHenrique]

@kathyang: For me, the most helpful would be to have the F# WinUI GUI project template for Visual Studio 2019, that has a WinUI XAML Type Provider, that allows to use the regular XAML editor, but having the F# Code Behind, in Gjallarhorn and/or Elmish.

[charlesroddie]

@kathyang The basic thing needed is to allow UWP to be installed via a nuget package. This will allow use of UWP views from any .Net language.

Work to make help type providers would be appreciated but would require some detailed discussion. It's hard to see how the community can maintain 3 type providers, especially because it's currently one person @ReedCopsey doing this (with the FsXaml WPF type provider). A UWP type provider developed separately wouldn't have the usage to justify the work in the near future. If there could be some consolidation of the various Xaml flavours then type providers could be made for WPF/UWP/XF that share the same structure. These type providers wouldn't need have support for all possible Xaml as F# usage doesn't have the same priorities (C# devs often advocate no code in View projects which then requires code-like features in Xaml).

[kathyang]

@TonyHenrique Thanks for your answer! I'll be sharing it with the team as a option.

@charlesroddie That's a good point about type providers. Could you clarify for me - when you said "allow UWP to be installed via a nuget package. This will allow use of UWP views from any .Net language", do you mean something different from this?

[charlesroddie]

@kathyang Microsoft.UI.Xaml is the right type of thing (naming aside). If this can be made to work in any .Net project, and contains all the UWP View classes, then it would be the main step in F# support.

Currently Microsoft.UI.Xaml works in special UWP projects (and there is no such project for F#), but not in .Net Standard projects (The namespace UI is not defined).

[kathyang]

Thank you to everyone for your helpful knowledge! Our team has discussed this and determined that we don't have the resources to invest in this right now as we're focusing on WinUI 2.2 and WinUI 3 and many important features going into these releases. Once WinUI 3 ships and the XAML framework is decoupled from the OS, we and the community can revisit this together. I’m adding the needs-winui-3 label to this issue, and please continue to share your comments on F# support in this discussion so your voice is heard when we come back to this later!

[bmitc]

Is there any update on this?

[xperiandri]

What kind(s) of support would be most helpful when creating F# apps?
Fix #5402 🙂

I made https://github.com/xperiandri/Elmish.Uno production-ready after the initial work of @jeromelaban.
I have a first-ever enterprise-grade Elmish template working with UWP and all Uno-supported platforms.
You can try it via dotnet new -i "Elmish.Uno.ProjectTemplates.Dotnet::1.0.0-ci-*" --nuget-source "https://www.myget.org/F/elmish_uno/api/v3/index.json"
But after I moved all C# UWP code to F# for WinUI on .NET 5 it no longer works 🙁.

[NickDarvey]

What would it take to move this feature out of the freezer?

[Happypig375]

XAML Standard is dead. For F# app development look to:

• https://github.com/fabulous-dev/Fabulous.Avalonia
• https://github.com/fsprojects/Avalonia.FuncUI
• https://github.com/RonaldSchlenker/Vide
• https://github.com/JordanMarr/Elmish.Avalonia

[NickDarvey]

@Happypig375, I guess you mean https://github.com/microsoft/xaml-standard?
I wasn't hoping to write any XAML, I wanted to write an app with WinAppSDK and F#.

[Happypig375]

@NickDarvey Ah oops I read the name of this repository wrong. But alternatives are still there for F# desktop development - through Avalonia.