重复 #736

重复 #736

这是将其添加到路线图文档的 PR - 我们也希望有一个问题来跟踪它😊

@jesbis足够公平。 F# 越多越好。 让人们开心，并确保 WinUI 3.0 包含尽可能多的 Microsoft 开发平台。 😀

F#我看到了两个重要的方法：
1) 使 F#（可变）记录 XAML 绑定友好/Gjallarhorn；

2) Elmish 风格

两者都可以支持，并有样品。 也许在未来只有一种趋势会被更多地使用。

我们将需要用于 .NET 5 上的 UI 的 F# 项目模板

在单个项目中混合和匹配 F# 和 C# 会很棒。 使用 F# 处理数据，使用 C# 处理 UI/命令。

仅 F# + GUI 应该可以完美运行，独立运行。
例如，仅 AF# 的解决方案将兼容，例如，使用来自 Azure 函数 + F# 的记录并将其以双向方式绑定到文本框。

F# 中的 UI/命令看起来非常简单和酷！

@jesbis

1. 启用对应用程序业务逻辑使用 F# | 必须
2. 启用混合和匹配语言（例如 F# 用于数据和逻辑，C# 用于 UI + 绑定）| 可以

这些看起来相同，并且通过允许引用 WinUI 的 C# 项目也引用任何 .Net 项目来暗示。 这应该是给定的（假设您可以通过安装 nuget 包来访问 WinUI）。

（但如果 5. 意味着在同一个项目中混合和匹配语言，那是不可能的，因为 C# 和 F# 之间的顺序不同。）

1. 启用对 Xaml 应用程序使用 Visual Studio F# 工具 | 必须

你能澄清一下吗？ “Xaml”目前非常混乱。 如果“Xaml”表示标记语言，那么这是一个复杂的问题，可能需要通过类型提供程序来解决（请参阅下面的链接）。 但是，如果“Xaml 应用程序”的意思是“WinUI 应用程序”，那么这只是 1.x 的一部分。

1. 启用对 Xaml 页面代码隐藏部分类使用 F# | 可以

请参阅此处对部分类/XAML 类型提供程序/BAML 编译的讨论： https :

目前无法在 F# 中构建 UWP UI。 通过传送整个 UI 层（按照 Win UI 3.0 中的计划），这至少是可能的，我迫不及待地期待它。

1：现有的 xlang 支持是否足够（使用新样本）？
个人认为，基本模板会很好。

2：哪些类型的模板或样本会有用？
基本示例将是一个不错的起点。

3：这是否应该包括支持 Xaml 页面代码隐藏文件？
我认为很多 F# 开发人员更喜欢 MVU 方法来构建 UI。
典型的 XAML + MVVM 依赖于可变性，像 UWP 特有的Fabolous这样的东西将是一个巨大的卖点（在我看来）。
基本上 Elm / React 就像 MVU 抽象一样更通用。

4：这可以/应该包括在项目中混合语言吗？
可以想象这会变得混乱。 F# 取决于文件顺序。

我要注意的是，支持 .NET Core 完全意味着支持 F#。 因此，如果目标是支持 .NET Core 3.0，那么 F# 支持就会随之而来。 然而，这_不_意味着一定程度的工具支持，例如设计师。

如果 F#（可变）记录 XAML 是绑定友好的，并且我们有一些示例，包括 UI 命令，我认为设计器将使用来自 C# 的相同工具，并且我们将在 F# 中拥有“代码隐藏”+ 数据对象.

例如：如何制作具有客户、发票、发票项目的发票屏幕的 WinUI GUI。 使用按钮新建发票，选择客户，添加/删除发票项目。

如何在 F# 中建模并将数据绑定到 UI，并将按钮命令绑定到 F# 函数？

@TonyHenrique .Net UI（WPF/UWP/Xamarin/

最好将 xaml 纯粹用于设计，并让类型提供程序提供对 UI 对象的访问权限（如 WPF 的 FsXaml）。

WinUI XAML F# 类型提供程序是将 UI 代码与事件和数据绑定代码分开的一种很酷的方法。

这样做后，我们将能够使用常规的 WinUI XAML 设计时编辑器。

（在 elmish 中让我担心的是，对于大型、复杂的 UI，混合在代码中，它往往看起来像旧的 php 意大利面条式代码。
Gjallarhorn也不错。 由 F# 团队为我们选择最好的）

现在，请使用适当的 UI/代码分离示例发布它，具有 WinUI .xaml 文件和 .fs 文件，就像我说的那样，具有 3 个级别项目的窗口：客户、发票、发票项目和添加/删除项目按钮， 例如。

我认为有了这个和 _Azure Functions F# 项目模板_，在我的新项目中完全切换到 F# 会很容易。

可以做的另一件事是在 C#/F# 代码中允许 XAML 文字。
这将启用这样的代码

let myButton title = <Button Text=title />

对于像我这样的 XAML 爱好者来说，它看起来很熟悉，而且看起来也像 React 代码。

不，谢谢，我对 Fabulous/Fable 声明视图的方式感到满意。

@tonyhenrique我不同意。 我们应该如何在 F# 中开发 UI 不是由 MS 决定的。 有足够的空间用于多种方法，尽管我个人更喜欢 Elmish 风格，因为它充分利用了 F# 而不必到处乱用可变数据结构。

@isaacabraham是否可以将 Elmish MVU 与 WinUI XAML 类型提供程序一起使用，并在单独的 XAML 文件中包含 UI 声明？ 这将允许使用常规 XAML 编辑器，但具有 F# 的不变性和类型安全性。

关于MS决定这一点，有很多优点。 为所选方式（无论是绑定可变记录、gjallahorn 还是 elmish 与单独的 XAML 文件）拥有合适的 F# GUI Visual Studio 项目模板会很棒。
我会非常有兴趣看到这个。

我无法对 WinUI 发表评论，但我们在纯 F# 解决方案中提供了 WPF 应用程序，这些应用程序使用内置的 VS XAML 设计器 + XAML 类型提供程序。 尽管我们今天可能会使用 Elmish WPF 库，但我们使用了 FSharp.ViewModule。

关于模板，我对它们有复杂的感觉。 首先，虽然它们可用作提高营销和意识的工具，但它们难以改变且不灵活。 恕我直言，一个更好的解决方案是 dotnet 模板和/或 nuget 包 - 更专注于代码而不是耦合到 VS - 我们已经（或应该离开）恕我直言。

这也直接回到这是一个“MS”决定还是社区主导的决定。 与其依赖 MS 来决定这是什么样子，为什么不积极主动地创造一些东西，而无需等待/依赖其他人。

谢谢@mdtauk @TonyHenrique @charlesroddie @JaggerJo @cartermp @Happypig375 @isaacabraham和其他人对这个问题的深思熟虑的评论！ 我正在帮助 UWP Xaml 团队确定是否以及如何投资 F# 支持。 在创建 F# 应用程序时，哪种支持最有帮助？

@kathyang ：对我来说，最有帮助的是为 Visual Studio 2019 提供 F# WinUI GUI 项目模板，它有一个WinUI XAML 类型提供程序，允许使用常规 XAML 编辑器，但在 Gjallarhorn 中

@kathyang所需的基本内容是允许通过 nuget 包安装 UWP。 这将允许使用来自任何 .Net 语言的 UWP 视图。

制作帮助类型提供者的工作将不胜感激，但需要一些详细的讨论。 很难看出社区如何维护 3 个类型提供程序，特别是因为目前只有一个人@ReedCopsey这样做（使用 FsXaml WPF 类型提供程序）。 在不久的将来，单独开发的 UWP 类型提供程序将无法用于证明工作的合理性。 如果可以合并各种 Xaml 风格，则可以为共享相同结构的 WPF/UWP/XF 创建类型提供程序。 这些类型提供程序不需要支持所有可能的 Xaml，因为 F# 使用没有相同的优先级（C# 开发人员通常提倡在 View 项目中没有代码，然后需要在 Xaml 中使用类似代码的功能）。

@TonyHenrique感谢您的回答！ 作为一种选择，我将与团队共享它。

@charlesroddie这是关于类型提供程序的一个很好的观点。 您能否为我澄清一下 - 当您说“允许通过 nuget 包安装 UWP。这将允许使用来自任何 .Net 语言的 UWP 视图”时，您的意思是否与此不同？

@kathyang Microsoft.UI.Xaml 是正确的类型（

目前 Microsoft.UI.Xaml 可用于特殊的 UWP 项目（F# 没有此类项目），但不适用于 .Net Standard 项目 ( The namespace UI is not defined )。

感谢大家提供的有用知识！ 我们的团队已经讨论过这个问题并确定我们现在没有资源来投资这个，因为我们专注于 WinUI 2.2 和 WinUI 3 以及这些版本中的许多重要功能。 一旦 WinUI 3 发布并且 XAML 框架与操作系统分离，我们和社区就可以一起重新审视这一点。 我在这个问题上添加了 Needs-winui-3 标签，请继续在此讨论中分享您对 F# 支持的评论，以便我们稍后再讨论时听到您的声音！