＃736の複製

＃736の複製

これはロードマップドキュメントに追加するためのPRです-これも追跡するための問題があります😊

@jesbisまあまあ。 F＃が多いほど良いです。 人々を幸せに保ち、WinUI3.0が可能な限り多くのMicrosoft開発プラットフォームを網羅するようにします。 😀

F＃2つの重要なアプローチがあります。
1）F＃（可変）レコードをXAMLバインディングフレンドリーにする/ Gjallarhorn;

2）エルミッシュスタイル

両方ともサポートされ、サンプルがあります。 たぶん将来的には1つのトレンドだけがもっと使われるようになるでしょう。

.NET 5のUI用のF＃プロジェクトテンプレートが必要になります

1つのプロジェクトでF＃とC＃を組み合わせて使用​​するのは素晴らしいことです。 データにはF＃を使用し、UI /コマンドにはC＃を使用します。

F＃のみ+ GUIは、スタンドアロンで完全に機能するはずです。
たとえば、AF＃のみのソリューションは、Azure Function + F＃からレコードを消費し、それをTwoWayでTextBoxにバインドするなどの互換性があります。

F＃でのUI /コマンドは非常にシンプルでクールに見えます！

@jesbis

1. アプリのビジネスロジックにF＃を使用できるようにする| しなければならない
2. 言語の混合とマッチングを有効にします（たとえば、データとロジックの場合はF＃、UI +バインディングの場合はC＃）| たぶん......だろう

これらは同じように見え、WinUIを参照するC＃プロジェクトが任意の.Netプロジェクトも参照できるようにすることで暗示されます。 それは当然のことです（nugetパッケージをインストールすることでWinUIにアクセスできると仮定します）。

（ただし、5。が同じプロジェクト内で言語を混合して一致させることを意味する場合、C＃とF＃の順序が異なるため、それは不可能です。）

1. XamlアプリでVisualStudio F＃ツールを使用できるようにする| しなければならない

これを明確にできますか？ 「Xaml」は現時点では非常に混乱しています。 「Xaml」がマークアップ言語を意味する場合、それはおそらくタイププロバイダーで解決される複雑な問題です（以下のリンクを参照）。 ただし、「Xamlアプリ」が「WinUIアプリ」を意味する場合、これは1の一部にすぎません。

1. 部分クラスの背後にあるXamlページコードにF＃を使用できるようにする| たぶん......だろう

https://github.com/dotnet/wpf/issues/162で、部分クラス/ XAMLタイププロバイダー/ BAMLコンパイルの説明を参照して

現在、F＃でUWPUIを構築することはできません。 （Win UI 3.0で計画されているように）UIレイヤー全体を出荷することで、これは少なくとも可能になります。私はそれを待ち望んでいます。

1：既存のxlangサポートは（新しいサンプルで）十分ですか？
個人的にはそれで大丈夫です、基本的なテンプレートがいいでしょう。

2：どのタイプのテンプレートまたはサンプルが役立ちますか？
基本的なサンプルは良い出発点になります。

3：これにはXamlページコードビハインドファイルのサポートを含める必要がありますか？
多くのF＃開発者は、UIの構築にMVUアプローチを好むと思います。
典型的なXAML + MVVMは可変性に依存しており、UWPに固有のFabolousのようなものが大きなセールスポイントになると思います（私の意見では）。
基本的にElm / MVU抽象化のように反応してより一般的になります。

4：これには、プロジェクトでの言語の混合が含まれる可能性がありますか？
これが乱雑になることを想像できます。 F＃はファイルの順序によって異なります。

.NET Coreをサポートすることは、F＃をサポートすることを完全に意味することに注意してください。 したがって、たとえば.NET Core 3.0のサポートが目標である場合、F＃サポートがそれに伴います。 ただし、これは、設計者などのツールサポートのレベルを意味するものではありません。

F＃（可変）レコードXAMLがバインドに適していて、UIコマンドが含まれている例がある場合、DesignerはC＃の同じツールで動作し、F＃に「コードビハインド」+データオブジェクトがあると思います。 。

例：顧客、請求書、請求書アイテムがある請求書画面のWinUIGUIを実行する方法。 [新しい請求書]ボタンを使用して、[顧客]、[請求書アイテムの追加/削除]を選択します。

F＃でモデル化し、データをUIにバインドし、ButtonコマンドをF＃関数にバインドする方法は？

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

純粋に設計のためにxamlを使用し、タイププロバイダーにUIオブジェクトへのアクセスを許可させることをお勧めします（WPFのFsXamlのように）。

WinUI XAML F＃タイププロバイダーは、UIコードをイベントおよびデータバインディングコードから分離するための

これにより、通常のWinUIXAMLデザインタイムエディターを使用できるようになります。

（エルミッシュで私が心配しているのは、コード内に混在する大きくて複雑なUIの場合、古いphpスパゲッティコードのように見える傾向があることです。
ギャラルホルンもいいです。 私たちに最適なものを選択するのはF＃チーム次第です）

ここで、適切なUI /コード分離サンプルを使用してリリースしてください。WinUI.xamlファイルと.fsファイルには、前述のように、顧客、請求書、請求書アイテム、アイテムの追加/削除ボタンの3つのレベルのアイテムを含むウィンドウがあります。 、 例えば。

これと_AzureFunctions F＃プロジェクトテンプレート_を使用すると、新しいプロジェクトでF＃に完全に切り替えるのが簡単になると思います。

実行できるもう1つのことは、C＃/ F＃コードでXAMLリテラルを許可することです。
これにより、次のようなコードが有効になります

let myButton title = <Button Text=title />

私のようなXAMLファンにはなじみがあり、Reactコードのようにも見えます。

いいえ、私は意見を宣言する素晴らしい/寓話的な方法に満足しています。

@tonyhenrique私は同意し

@isaacabraham WinUI XAMLタイププロバイダーでElmishMVUを使用し、別のXAMLファイルでUI宣言を使用することは可能ですか？ これにより、通常のXAMLエディターを使用できますが、F＃の不変性と型の安全性があります。

これを決定するMSについては、多くの利点があります。 選択した方法（可変レコード、gjallahorn、またはelmishを個別のXAMLファイルにバインドするかどうか）に適切なF＃GUI VisualStudioプロジェクトテンプレートがあると便利です。
私はこれを見たいと思っています。

WinUIについてコメントすることはできませんが、組み込みのVS XAMLデザイナーとXAMLタイププロバイダーを使用する純粋なF＃ソリューションのWPFアプリがあります。 今日はおそらくElmishWPFライブラリを使用しますが、FSharp.ViewModuleを使用しました。

テンプレートに関しては、私はそれらについて複雑な気持ちを持っています。 第一に、それらはマーケティングと意識を高めるためのツールとしては有用ですが、変更するのは難しく、柔軟性がありません。 IMHOのより良い解決策は、ドットネットテンプレートやnugetパッケージ（VSに結合されるのではなくコードに焦点を当てたもの）です。私たちはそのIMHOから移行しました（または移行する必要があります）。

これは、これが「MS」の決定なのか、コミュニティ主導の決定なのかということにも直結します。 これがどのように見えるかを決定するためにMSに頼るのではなく、他の誰かを待ったり頼ったりせずに積極的に何かを作成してみませんか。

この問題についてのあなたの思慮深いコメントをお@mdtauk @TonyHenrique @charlesroddie @JaggerJo @cartermp @ Happypig375 @isaacabrahamなどをありがとうございました！ 私は、UWP XamlチームがF＃サポートに投資するかどうかとその方法を決定するのを支援しています。 F＃アプリを作成するときに最も役立つサポートの種類は何ですか？

@kathyang ：私にとって最も役立つのは、Visual Studio 2019用のF＃WinUI GUIプロジェクトテンプレートを用意することです。これには、 WinUI XAMLタイププロバイダーがあり、通常のXAMLエディターを使用できますが、GjallarhornにF＃コードビハインドがあります。および/またはエルミッシュ。

@kathyang必要な基本的なことは、UWPをnugetパッケージを介してインストールできるようにすることです。 これにより、任意の.Net言語からのUWPビューを使用できるようになります。

ヘルプタイプのプロバイダーを作成する作業はありがたいですが、詳細な議論が必要になります。 コミュニティが3つのタイププロバイダーを維持する方法を理解するのは困難です。特に、現在@ReedCopseyがこれを行っているのは1人であるためです（FsXaml WPFタイププロバイダーを使用）。 個別に開発されたUWPタイプのプロバイダーは、近い将来、作業を正当化するための使用法がありません。 さまざまなXamlフレーバーを統合できる場合は、同じ構造を共有するWPF / UWP / XFの型プロバイダーを作成できます。 F＃の使用法には同じ優先順位がないため、これらのタイププロバイダーは、考えられるすべてのXamlをサポートする必要はありません（C＃開発者は、Viewプロジェクトでコードを推奨しないことが多く、Xamlでコードのような機能が必要になります）。

@TonyHenriqueご回答ありがとうございます！ オプションでチームと共有します。

@charlesroddieそれはタイププロバイダーの良い点です。 あなたは私のために明確でした-あなたが言ったときから、あなたに平均何か別の操作を行う「UWPはnugetパッケージ経由でインストールできるようにする。これは、任意の.NET言語からUWPビューを使用することができるようになります。」この？

@kathyang Microsoft.UI.Xamlは正しいタイプのものです（名前は別として）。 これを任意の.Netプロジェクトで機能させることができ、すべてのUWPビュークラスが含まれている場合は、F＃サポートのメインステップになります。

現在、Microsoft.UI.Xamlは特別なUWPプロジェクトで機能します（F＃用のそのようなプロジェクトはありません）が、.Net Standardプロジェクト（ The namespace UI is not defined ）では機能しません。

皆様の有益な知識に感謝します！ 私たちのチームはこれについて話し合い、WinUI2.2とWinUI3、およびこれらのリリースに含まれる多くの重要な機能に焦点を合わせているため、現時点ではこれに投資するためのリソースがないと判断しました。 WinUI 3が出荷され、XAMLフレームワークがOSから切り離されると、私たちとコミュニティは一緒にこれを再検討できます。 この問題にneeds-winui-3ラベルを追加します。このディスカッションでは、F＃サポートに関するコメントを引き続き共有してください。そうすれば、後でこの問題に戻ったときにあなたの声が聞こえます。