Duplikat #736

Duplikat #736

Itu PR untuk menambahkannya ke dokumen peta jalan - kami ingin memiliki masalah untuk melacak ini juga 😊

@jesbis Cukup adil. Semakin banyak F# semakin baik. Buat orang senang, dan pastikan WinUI 3.0 mencakup sebanyak mungkin platform pengembang Microsoft. 😀

F# Saya melihat dua pendekatan penting:
1) Jadikan Catatan F# (bisa berubah) XAML Binding Friendly / Gjallarhorn;

2) gaya Elmish

Keduanya dapat didukung, dan memiliki sampel. Mungkin di masa depan hanya 1 tren yang lebih banyak digunakan.

Kita akan membutuhkan F# Project Templates untuk UI di .NET 5

Akan sangat bagus untuk mencampur dan mencocokkan F# dan C# dalam satu proyek. Gunakan F# untuk hal-hal data, dan C# untuk UI/Perintah.

F# only + GUI harus bekerja dengan sempurna, mandiri.
Solusi satu-satunya AF# akan kompatibel misalnya, dengan menggunakan Record dari Azure Function + F# dan Bind it TwoWay ke TextBox, misalnya.

UI/Perintah di F# akan terlihat sangat sederhana dan keren!

@jesbis

1. Aktifkan menggunakan F# untuk logika bisnis aplikasi | Harus
2. Aktifkan pencampuran dan pencocokan bahasa (misalnya F# untuk data dan logika, C# untuk UI + binding) | Bisa

Ini tampak sama, dan tersirat dengan mengizinkan proyek C# yang mereferensikan WinUI untuk juga merujuk proyek .Net apa pun. Itu harus diberikan (dengan asumsi Anda dapat mengakses WinUI dengan menginstal paket nuget).

(Tetapi jika 5. berarti mencampur dan mencocokkan bahasa dalam proyek yang sama , itu tidak mungkin karena perbedaan urutan antara C# dan F#.)

1. Aktifkan menggunakan alat Visual Studio F# dengan aplikasi Xaml | Harus

Bisakah Anda mengklarifikasi ini? "Xaml" sangat membingungkan saat ini. Jika "Xaml" berarti bahasa markup, maka ini adalah masalah kompleks yang mungkin diselesaikan dengan penyedia tipe (lihat tautan di bawah). Tetapi jika "aplikasi Xaml" berarti "aplikasi WinUI" maka ini hanya bagian dari 1.

1. Aktifkan menggunakan F# untuk kode halaman Xaml di belakang kelas parsial | Bisa

Lihat diskusi tentang kelas parsial/penyedia tipe XAML/kompilasi BAML di sini: https://github.com/dotnet/wpf/issues/162 .

Saat ini tidak mungkin untuk membangun UI UWP di F#. Dengan mengirimkan seluruh Lapisan UI (seperti yang direncanakan di Win UI 3.0) ini setidaknya akan mungkin, dan saya tidak sabar menantikannya.

1: Apakah dukungan xlang yang ada cukup (dengan sampel baru)?
Secara pribadi baik-baik saja dengan itu, template dasar akan menyenangkan.

2: Jenis templat atau sampel apa yang berguna?
Sampel dasar akan menjadi titik awal yang bagus.

3: Haruskah ini termasuk mendukung file codebehind halaman Xaml?
Saya pikir banyak Pengembang F# lebih suka pendekatan MVU untuk membangun UI.
XAML + MVVM yang khas bergantung pada mutabilitas, sesuatu seperti Fabolous khusus untuk UWP akan menjadi nilai jual yang sangat besar (menurut saya).
Pada dasarnya Elm / Bereaksi seperti abstraksi MVU menjadi lebih umum.

4: Bisakah/haruskah ini mencakup pencampuran bahasa dalam sebuah proyek?
Dapat membayangkan ini menjadi berantakan. F# tergantung pada urutan file.

Sesuatu yang saya perhatikan adalah bahwa mendukung .NET Core sepenuhnya menyiratkan mendukung F#. Jadi jika tujuannya adalah, misalnya, mendukung .NET Core 3.0, maka dukungan F# akan menyertainya. Namun ini _not_ menyiratkan tingkat dukungan perkakas, seperti desainer.

Jika F# (bisa berubah) Records XAML Binding Friendly dan kami memiliki beberapa contoh, dengan Perintah UI disertakan, saya pikir Perancang akan bekerja dengan perkakas yang sama dari C#, dan kami akan memiliki "kode di belakang" + Objek data di F# .

Misalnya: Bagaimana melakukan GUI WinUI dari layar Faktur yang memiliki Pelanggan, Faktur, Item Faktur. Dengan tombol Faktur Baru, pilih pelanggan, Tambah / Hapus Item Faktur.

Bagaimana memodelkannya dalam F# dan Mengikat Data ke UI, dan Mengikat perintah Tombol ke fungsi F#?

@TonyHenrique Pendekatan pengikatan asli di .Net UI (WPF/UWP/Xamarin/Avalonia) memiliki kelemahan parah: kurangnya keamanan tipe, implementasi peta yang diretas ("konverter"), string ajaib di mana-mana. Tidak cocok untuk F#. Lebih baik mengabaikan infrastruktur ini dan menggunakan pendekatan fungsional moderat (pendekatan reaktif seperti Gjallarhorn - Anda mungkin melihat ini sebagai implementasi pengikatan yang dilakukan dengan benar) atau pendekatan fungsional ekstrem (Elmish, misalnya Fabulous).

Lebih baik menggunakan xaml murni untuk desain dan memiliki penyedia tipe yang memberikan akses ke objek UI (seperti dalam FsXaml untuk WPF).

Penyedia tipe WinUI XAML F# akan menjadi pendekatan yang keren untuk memisahkan kode UI dari peristiwa dan kode pengikatan data.

Dengan melakukan ini, kita akan dapat menggunakan editor Waktu Desain XAML WinUI biasa.

(Yang membuat saya khawatir dalam bahasa elmish adalah bahwa untuk UI yang besar dan kompleks, dicampur di dalam kode, Ini cenderung terlihat seperti kode spaghetti php lama.
Gjallarhorn juga bagus. Terserah tim F# untuk memilih yang terbaik untuk kita)

Sekarang, silakan lepaskan dengan sampel pemisahan UI/kode yang tepat, yang memiliki file .xaml WinUI dan file .fs dengan, seperti yang saya katakan, Jendela dengan 3 item level: pelanggan, faktur, item faktur, dan tombol tambah/hapus item , Misalnya.

Saya pikir dengan ini dan _Azure Functions F# Project Template_ akan mudah untuk beralih sepenuhnya ke F# pada proyek baru saya.

Hal lain yang dapat dilakukan adalah mengizinkan literal XAML dalam kode C#/F#.
Ini akan mengaktifkan kode seperti ini

let myButton title = <Button Text=title />

dan itu akan terlihat familier bagi penggemar XAML seperti saya, dan juga terlihat seperti kode React.

Tidak, terima kasih, saya puas dengan cara Fabulous/Fable dalam mendeklarasikan tampilan.

@tonyhenrique saya tidak setuju. Tidak tergantung pada MS untuk memutuskan bagaimana kita harus mengembangkan UI di F#. Ada cukup ruang untuk beberapa pendekatan, meskipun saya pribadi lebih suka gaya Elmish karena mengambil keuntungan penuh dari F# daripada harus dipusingkan dengan struktur data yang bisa berubah di mana-mana.

@isaacabraham Apakah mungkin menggunakan Elmish MVU, dengan Penyedia Jenis XAML WinUI, dan memiliki deklarasi UI dalam file XAML terpisah? Ini akan memungkinkan untuk menggunakan editor XAML biasa, tetapi memiliki kekekalan dan keamanan tipe F#.

Tentang MS memutuskan ini, ada banyak keuntungan. Memiliki template F# GUI Visual Studio Project yang tepat untuk cara yang dipilih (apakah: mengikat catatan yang dapat diubah, gjallahorn, atau elmish dengan file XAML terpisah) akan luar biasa.
Saya akan sangat tertarik melihat ini.

Saya tidak dapat mengomentari WinUI tetapi kami memiliki aplikasi WPF dalam solusi F # murni yang menggunakan perancang VS XAML bawaan + Penyedia Jenis XAML. Kami menggunakan FSharp.ViewModule meskipun hari ini kami mungkin menggunakan perpustakaan Elmish WPF.

Mengenai template, saya memiliki perasaan campur aduk tentang mereka. Pertama, meskipun mereka berguna sebagai alat untuk meningkatkan pemasaran dan kesadaran, mereka sulit diubah dan tidak fleksibel. Solusi IMHO yang lebih baik adalah templat dotnet dan/atau paket nuget - sesuatu yang lebih fokus pada kode daripada digabungkan ke dalam VS - kami telah pindah (atau harus pindah) dari IMHO itu.

Ini juga kembali ke apakah ini keputusan "MS" atau sesuatu yang dipimpin komunitas atau tidak. Daripada mengandalkan MS untuk memutuskan seperti apa ini, mengapa tidak proaktif dan membuat sesuatu tanpa menunggu / bergantung pada orang lain.

Terima kasih @mdtauk @TonyHenrique @charlesroddie @JaggerJo @cartermp @Happypig375 @isaacabraham dan lainnya atas komentar bijaksana Anda tentang masalah ini! Saya membantu tim UWP Xaml untuk menentukan apakah dan bagaimana berinvestasi dalam dukungan F#. Jenis dukungan apa yang paling membantu saat membuat aplikasi F#?

@kathyang : Bagi saya, yang paling membantu adalah memiliki template proyek GUI F# WinUI untuk Visual Studio 2019 , yang memiliki Penyedia Jenis XAML WinUI , yang memungkinkan untuk menggunakan editor XAML biasa, tetapi memiliki Kode F# Di Belakang, di Gjallarhorn dan/atau Elmish.

@kathyang Hal dasar yang diperlukan adalah mengizinkan UWP diinstal melalui paket nuget. Ini akan memungkinkan penggunaan tampilan UWP dari bahasa .Net apa pun.

Pekerjaan untuk membuat penyedia jenis bantuan akan dihargai tetapi akan membutuhkan beberapa diskusi terperinci. Sulit untuk melihat bagaimana komunitas dapat mempertahankan 3 jenis penyedia, terutama karena saat ini satu orang @ReedCopsey melakukan ini (dengan penyedia jenis FsXaml WPF). Penyedia tipe UWP yang dikembangkan secara terpisah tidak akan dapat digunakan untuk membenarkan pekerjaan dalam waktu dekat. Jika mungkin ada beberapa konsolidasi dari berbagai rasa Xaml maka penyedia tipe dapat dibuat untuk WPF/UWP/XF yang memiliki struktur yang sama. Penyedia jenis ini tidak perlu memiliki dukungan untuk semua kemungkinan Xaml karena penggunaan F# tidak memiliki prioritas yang sama (pengembang C# sering menganjurkan tidak ada kode dalam proyek Lihat yang kemudian memerlukan fitur seperti kode di Xaml).

@TonyHenrique Terima kasih atas jawaban Anda! Saya akan membagikannya dengan tim sebagai opsi.

@charlesroddie Itu poin bagus tentang penyedia tipe. Bisakah Anda mengklarifikasi untuk saya - ketika Anda mengatakan "izinkan UWP diinstal melalui paket nuget. Ini akan memungkinkan penggunaan tampilan UWP dari bahasa .Net apa pun", maksud Anda sesuatu yang berbeda dari ini ?

@kathyang Microsoft.UI.Xaml adalah jenis yang tepat (selain penamaan). Jika ini dapat dibuat untuk bekerja di proyek .Net apa pun, dan berisi semua kelas UWP View, maka itu akan menjadi langkah utama dalam dukungan F#.

Saat ini Microsoft.UI.Xaml bekerja dalam proyek UWP khusus (dan tidak ada proyek seperti itu untuk F#), tetapi tidak dalam proyek .Net Standard ( The namespace UI is not defined ).

Terima kasih kepada semua orang atas pengetahuan Anda yang bermanfaat! Tim kami telah membahas hal ini dan memutuskan bahwa kami tidak memiliki sumber daya untuk berinvestasi dalam hal ini sekarang karena kami berfokus pada WinUI 2.2 dan WinUI 3 dan banyak fitur penting yang masuk ke dalam rilis ini. Setelah WinUI 3 dikirimkan dan kerangka kerja XAML dipisahkan dari OS, kami dan komunitas dapat meninjaunya kembali bersama-sama. Saya menambahkan label need-winui-3 untuk masalah ini, dan tolong terus bagikan komentar Anda tentang dukungan F# dalam diskusi ini sehingga suara Anda terdengar saat kami kembali membahas ini nanti!