Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Better F# support #740

Open
jesbis opened this issue May 22, 2019 · 23 comments

Comments

@jesbis
Copy link
Member

commented May 22, 2019

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

This comment has been minimized.

Copy link

commented May 22, 2019

Duplicate of #736

@jesbis

This comment has been minimized.

Copy link
Member Author

commented May 22, 2019

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

This comment has been minimized.

Copy link

commented May 22, 2019

@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. 😀

@msft-github-bot msft-github-bot added this to Freezer in Feature tracking May 22, 2019

@msft-github-bot msft-github-bot added this to Needs triage in Controls Triage May 22, 2019

@TonyHenrique

This comment has been minimized.

Copy link

commented May 22, 2019

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

This comment has been minimized.

Copy link

commented May 22, 2019

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

This comment has been minimized.

Copy link

commented May 22, 2019

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

This comment has been minimized.

Copy link

commented May 23, 2019

@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#.)

  1. 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.

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

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

@YuliKl YuliKl added this to Needs triage in Markup Triage via automation May 23, 2019

@YuliKl YuliKl removed this from Needs triage in Controls Triage May 23, 2019

@JaggerJo

This comment has been minimized.

Copy link

commented May 30, 2019

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

This comment has been minimized.

Copy link

commented May 31, 2019

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

This comment has been minimized.

Copy link

commented May 31, 2019

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

This comment has been minimized.

Copy link

commented Jun 1, 2019

@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

This comment has been minimized.

Copy link

commented Jun 1, 2019

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

This comment has been minimized.

Copy link

commented Jun 5, 2019

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

This comment has been minimized.

Copy link

commented Jun 6, 2019

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

@isaacabraham

This comment has been minimized.

Copy link

commented Jun 7, 2019

@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

This comment has been minimized.

Copy link

commented Jun 7, 2019

@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

This comment has been minimized.

Copy link

commented Jun 12, 2019

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

This comment has been minimized.

Copy link

commented Jun 12, 2019

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

This comment has been minimized.

Copy link

commented Jun 12, 2019

@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

This comment has been minimized.

Copy link

commented Jun 14, 2019

@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

This comment has been minimized.

Copy link

commented Jun 14, 2019

@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

This comment has been minimized.

Copy link

commented Jun 15, 2019

@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

This comment has been minimized.

Copy link

commented Jun 17, 2019

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.