Duplikat von #736

Duplikat von #736

Das ist eine PR, um es dem Roadmap-Dokument hinzuzufügen - wir hätten auch gerne ein Problem, um dies zu verfolgen 😊

@jesbis Fair genug. Je mehr F# desto besser. Machen Sie die Leute glücklich und stellen Sie sicher, dass WinUI 3.0 so viele Microsoft-Entwicklungsplattformen wie möglich umfasst. 😀

F# Ich sehe zwei wichtige Ansätze:
1) Machen Sie die F#-Datensätze (veränderlich) XAML-Bindungsfreundlich / Gjallarhorn;

2) Elmischer Stil

Beide könnten unterstützt werden und haben Proben. Vielleicht wird in Zukunft nur 1 Trend mehr verwendet.

Wir benötigen die F#-Projektvorlagen für die Benutzeroberfläche auf .NET 5

Es wäre großartig, F# und C# in einem einzigen Projekt zu kombinieren. Verwenden Sie F# für Daten und C# für UI/Commanding.

Nur F# + GUI sollte perfekt funktionieren, eigenständig.
Eine reine AF#-Lösung wäre beispielsweise mit dem Verbrauchen eines Datensatzes aus Azure Function + F# und dem Binden von zwei Möglichkeiten an eine TextBox beispielsweise kompatibel.

Eine Benutzeroberfläche/Befehlszeile in F# würde sehr einfach und cool aussehen!

@jesbis

1. Aktivieren der Verwendung von F# für App-Geschäftslogik | Muss
2. Mischen und Abgleichen von Sprachen aktivieren (z. B. F# für Daten und Logik, C# für Benutzeroberfläche + Bindungen) | Könnten

Diese scheinen gleich zu sein und werden dadurch impliziert, dass C#-Projekten, die auf WinUI verweisen, auch auf .NET-Projekte verweisen können. Das sollte selbstverständlich sein (vorausgesetzt, Sie können auf WinUI zugreifen, indem Sie ein Nuget-Paket installieren).

(Aber wenn 5. bedeutet, Sprachen innerhalb desselben Projekts zu mischen und abzugleichen, ist dies aufgrund von Reihenfolgeunterschieden zwischen C# und F# nicht möglich.)

1. Aktivieren der Verwendung von Visual Studio F#-Tools mit Xaml-Apps | Muss

Können Sie das klären? "Xaml" ist im Moment sehr verwirrend. Wenn "Xaml" die Auszeichnungssprache bedeutet, ist dies ein komplexes Problem, das möglicherweise mit einem Typanbieter gelöst werden kann (siehe Link unten). Aber wenn "Xaml-Apps" "WinUI-Apps" bedeutet, dann ist dies nur ein Teil von 1.

1. Aktivieren der Verwendung von F# für Xaml-Seitencodebehind partiellen Klassen | Könnten

Siehe die Diskussion über partielle Klassen/XAML-Typanbieter/BAML-Kompilierung hier: https://github.com/dotnet/wpf/issues/162 .

Derzeit ist es nicht möglich, UWP-UIs in F# zu erstellen. Mit der Auslieferung des gesamten UI-Layers (wie in Win UI 3.0 geplant) wird dies zumindest möglich sein, und ich freue mich schon ungeduldig darauf.

1: Ist die vorhandene xlang-Unterstützung ausreichend (bei neuen Beispielen)?
Persönlich ok damit, einfache Vorlagen wären schön.

2: Welche Arten von Vorlagen oder Mustern wären nützlich?
Basisbeispiele wären ein guter Ausgangspunkt.

3: Sollte dies die Unterstützung von Codebehind-Dateien für Xaml-Seiten umfassen?
Ich denke, viele F#-Entwickler würden einen MVU-Ansatz zum Erstellen von Benutzeroberflächen bevorzugen.
Typisches XAML + MVVM basiert auf Veränderlichkeit, etwas wie Fabolous spezifisch für UWP wäre ein großes Verkaufsargument (meiner Meinung nach).
Grundsätzlich sind Elm / React wie MVU-Abstraktionen allgemeiner.

4: Könnte/sollte dies das Mischen von Sprachen in einem Projekt beinhalten?
Kann mir vorstellen, dass das unordentlich wird. F# hängt von der Dateireihenfolge ab.

Ich möchte darauf hinweisen, dass die Unterstützung von .NET Core die vollständige Unterstützung von F# impliziert. Wenn ein Ziel also zB die Unterstützung von .NET Core 3.0 ist, dann kommt die F#-Unterstützung damit. Dies bedeutet jedoch _kein_ ein Maß an Werkzeugunterstützung, wie z. B. durch Konstrukteure.

Wenn die XAML-Datensätze von F# (veränderlich) bindungsfreundlich wären und wir ein Beispiel mit enthaltenen UI-Befehlen hätten, würde der Designer meiner Meinung nach mit den gleichen Tools wie C# arbeiten, und wir hätten den "Code dahinter" + Datenobjekte in F# .

Zum Beispiel: So erstellen Sie eine WinUI-GUI eines Rechnungsbildschirms mit Kunden, Rechnung und Rechnungspositionen. Wählen Sie mit den Schaltflächen Neue Rechnung Kunde, Rechnungspositionen hinzufügen/entfernen.

Wie kann man es in F# modellieren und die Daten an die Benutzeroberfläche binden und die Schaltflächenbefehle an F#-Funktionen binden?

@TonyHenrique Der native Bindungsansatz in .Net-UIs (WPF/UWP/Xamarin/Avalonia) hat gravierende Schwächen: völliger Mangel an Typsicherheit, hackige Implementierung von Maps ("Konverter"), magische Zeichenfolgen überall. Passt nicht gut zu F#. Es ist besser, diese Infrastruktur zu ignorieren und entweder moderate funktionale Ansätze (reaktive Ansätze wie Gjallarhorn - Sie könnten diese als richtig gemachte Implementierungen von Binding ansehen) oder extreme funktionale Ansätze (Elmish, zB Fabulous) zu verwenden.

Es ist besser, xaml nur für das Design zu verwenden und einen Typanbieter zu haben, der Zugriff auf die UI-Objekte gewährt (wie in FsXaml für WPF).

Ein Anbieter vom Typ WinUI XAML F# wäre ein cooler Ansatz, um den Benutzeroberflächencode von den Ereignissen und dem Datenbindungscode zu trennen.

Auf diese Weise können wir den regulären WinUI XAML Design Time Editor verwenden.

(Was mich auf Elmish beunruhigt, ist, dass es für große, komplexe Benutzeroberflächen, die in den Code gemischt sind, dazu neigt, wie alter PHP-Spaghetti-Code auszusehen.
Gjallarhorn ist auch schön. Es liegt am F#-Team, das Beste für uns auszuwählen)

Geben Sie es jetzt bitte mit einem richtigen UI/Code-Trennungsbeispiel heraus, das die WinUI-.xaml-Datei und eine .fs-Datei mit, wie gesagt, einem Fenster mit drei Elementen enthält: Kunde, Rechnung, Rechnungselemente und Schaltflächen zum Hinzufügen/Entfernen von Elementen , zum Beispiel.

Ich denke, dass es mit dieser und der _Azure Functions F#-Projektvorlage_ einfach sein wird, bei meinen neuen Projekten vollständig auf F# umzusteigen.

Eine andere Möglichkeit besteht darin, XAML-Literale in C#/F#-Code zuzulassen.
Dies würde Code wie diesen aktivieren

let myButton title = <Button Text=title />

und es würde XAML-Fans wie mir bekannt vorkommen und sieht auch aus wie React-Code.

Nein danke, ich bin zufrieden mit der Fabulous/Fable-Methode, Ansichten zu deklarieren.

@tonyhenrique Ich bin anderer Meinung. Es liegt nicht an MS zu entscheiden, wie wir UIs in F# entwickeln sollen. Es gibt genug Platz für mehrere Ansätze, obwohl ich persönlich den Elmish-Stil bevorzuge, weil er F# voll ausnutzt, anstatt überall mit veränderlichen Datenstrukturen herumspielen zu müssen.

@isaacabraham Ist es möglich, Elmish MVU mit einem WinUI-XAML-Typanbieter zu verwenden und die UI-Deklaration in einer separaten XAML-Datei zu haben? Dies würde die Verwendung des regulären XAML-Editors ermöglichen, jedoch mit der Unveränderlichkeit und Typsicherheit von F#.

Wenn MS dies entscheidet, gibt es viele Vorteile. Eine geeignete F#-GUI-Visual-Studio-Projektvorlage für den ausgewählten Weg (ob: Veränderliche Datensätze binden, gjallahorn oder elmish mit separater XAML-Datei zu binden) wäre großartig.
Das würde mich sehr interessieren.

Ich kann WinUI nicht kommentieren, aber wir haben WPF-Apps in einer reinen F#-Lösung, die den integrierten VS-XAML-Designer + den XAML-Typanbieter verwenden. Wir haben FSharp.ViewModule verwendet, obwohl wir heute wahrscheinlich die Elmish WPF-Bibliothek verwenden würden.

Was Vorlagen angeht, habe ich gemischte Gefühle. Erstens sind sie zwar ein nützliches Instrument zur Steigerung des Marketings und des Bewusstseins, aber sie sind schwer zu ändern und unflexibel. Eine bessere Lösung wäre IMHO eine Dotnet-Vorlage und / oder ein Nuget-Paket - etwas mehr Code-fokussiert als in VS gekoppelt - wir haben uns davon entfernt (oder sollten uns davon entfernen).

Dies kommt auch gleich darauf zurück, ob es sich um eine "MS"-Entscheidung handelt oder um etwas, das von der Gemeinschaft geführt wird oder nicht. Anstatt sich auf MS zu verlassen, um zu entscheiden, wie dies aussieht, warum nicht proaktiv sein und etwas erschaffen, ohne zu warten / sich auf jemand anderen zu verlassen.

Danke @mdtauk @TonyHenrique @charlesroddie @JaggerJo @cartermp @Happypig375 @isaacabraham und anderen für deine aufmerksamen Kommentare zu diesem Thema! Ich helfe dem UWP-Xaml-Team bei der Entscheidung, ob und wie in F#-Unterstützung investiert werden soll. Welche Art von Unterstützung wäre beim Erstellen von F#-Apps am hilfreichsten?

@kathyang : Am hilfreichsten wäre für mich die F# WinUI GUI-Projektvorlage für Visual Studio 2019 mit einem WinUI XAML Type Provider , der die Verwendung des regulären XAML-Editors ermöglicht, aber den F#

@kathyang Das

Die Arbeit an der Erstellung von Hilfetyp-Anbietern wäre wünschenswert, würde jedoch eine detaillierte Diskussion erfordern. Es ist schwer zu erkennen, wie die Community 3 Typanbieter verwalten kann, insbesondere weil dies derzeit von einer Person

@TonyHenrique Danke für deine Antwort! Ich werde es optional mit dem Team teilen.

@charlesroddie Das ist ein guter Punkt bei dies ?

@kathyang Microsoft.UI.Xaml ist die richtige Art von Dingen (Nennung beiseite). Wenn dies in jedem .NET-Projekt funktioniert und alle UWP-View-Klassen enthält, wäre dies der Hauptschritt bei der F#-Unterstützung.

Derzeit funktioniert Microsoft.UI.Xaml in speziellen UWP-Projekten (und es gibt kein solches Projekt für F#), aber nicht in .Net Standard-Projekten ( The namespace UI is not defined ).

Vielen Dank an alle für Ihr hilfreiches Wissen! Unser Team hat dies besprochen und festgestellt, dass wir derzeit nicht über die Ressourcen verfügen, um darin zu investieren, da wir uns auf WinUI 2.2 und WinUI 3 und viele wichtige Funktionen in diesen Versionen konzentrieren. Sobald WinUI 3 ausgeliefert und das XAML-Framework vom Betriebssystem entkoppelt ist, können wir und die Community dies gemeinsam überdenken. Ich füge dieser Ausgabe das Label Needs-winui-3 hinzu, und teilen Sie bitte weiterhin Ihre Kommentare zur F#-Unterstützung in dieser Diskussion mit, damit Ihre Stimme gehört wird, wenn wir später darauf zurückkommen!