نسخة مكررة من # 736

نسخة مكررة من # 736

هذه عبارة عن علاقات عامة لإضافتها إلى مستند خارطة الطريق - نود أن يكون لدينا مشكلة لتتبع هذا أيضًا 😊

jesbis عادل بما فيه الكفاية. كلما زاد عدد F # كان ذلك أفضل. اجعل الناس سعداء ، وتأكد من أن WinUI 3.0 يشمل أكبر قدر ممكن من منصات التطوير من Microsoft. 😀

F # أرى طريقتين مهمتين:
1) جعل F # (متغير) سجلات XAML ملزمة ودية / Gjallarhorn ؛

2) أسلوب الميش

يمكن دعم كلاهما ، ولهما عينات. ربما في المستقبل يتم استخدام اتجاه واحد فقط.

سنحتاج إلى قوالب مشروع F # لواجهة المستخدم على .NET 5

سيكون من الرائع المزج والمطابقة بين F # و C # في مشروع واحد. استخدم F # لمواد البيانات ، و C # لواجهة المستخدم / الأمر.

يجب أن تعمل F # only + GUI بشكل مثالي ومستقل.
سيكون حل AF # الوحيد متوافقًا على سبيل المثال ، مع استهلاك سجل من وظيفة Azure + F # وربطه بطريقتين إلى TextBox ، على سبيل المثال.

ستبدو واجهة المستخدم / الأمر في F # بسيطة جدًا ورائعة!

تضمين التغريدة

1. تفعيل استخدام F # لمنطق عمل التطبيق | يجب
2. تفعيل لغات المزج والمطابقة (مثل F # للبيانات والمنطق ، C # لواجهة المستخدم + روابط) | استطاع

تبدو هذه هي نفسها ، ويتم تضمينها من خلال السماح لمشاريع C # التي تشير إلى WinUI أيضًا بالإشارة إلى أي من مشاريع .NET. يجب أن يكون هذا معطى (على افتراض أنه يمكنك الوصول إلى WinUI عن طريق تثبيت حزمة nuget).

(ولكن إذا كانت 5. تعني مزج ومطابقة اللغات في نفس المشروع ، فهذا غير ممكن بسبب اختلافات الترتيب بين C # و F #.)

1. تمكين استخدام أدوات Visual Studio F # مع تطبيقات Xaml | يجب

هل يمكنك توضيح هذا؟ "Xaml" محير للغاية في الوقت الحالي. إذا كانت "Xaml" تعني لغة الترميز ، فمن المحتمل أن يتم حلها مع مزود النوع (انظر الرابط أدناه) مشكلة معقدة. ولكن إذا كانت "تطبيقات Xaml" تعني "تطبيقات WinUI" ، فهذا مجرد جزء من 1.

1. تفعيل استخدام F # لشفرة صفحة Xaml خلف الفصول الدراسية الجزئية | استطاع

انظر مناقشة الفئات الجزئية / موفرو نوع XAML / تجميع BAML هنا: https://github.com/dotnet/wpf/issues/162 .

لا يمكن حاليًا إنشاء واجهات مستخدم UWP في F #. من خلال شحن طبقة واجهة المستخدم بالكامل (كما هو مخطط في Win UI 3.0) ، سيكون هذا ممكنًا على الأقل ، وأنا أتطلع بفارغ الصبر إلى ذلك.

1: هل دعم xlang الحالي كافٍ (مع عينات جديدة)؟
شخصيًا موافق على ذلك ، ستكون القوالب الأساسية رائعة.

2: ما هي أنواع النماذج أو العينات التي ستكون مفيدة؟
ستكون العينات الأساسية نقطة انطلاق جيدة.

3: هل يجب أن يشمل ذلك دعم ملفات كود صفحة Xaml الخلفية؟
أعتقد أن الكثير من مطوري F # يفضلون نهج MVU لبناء واجهات المستخدم.
يعتمد XAML + MVVM النموذجي على قابلية التغيير ، شيء مثل Fabolous الخاص بـ UWP سيكون نقطة بيع ضخمة (في رأيي).
أساسًا Elm / React مثل MVU المجردة لتكون أكثر عمومية.

4: هل يمكن / يجب أن يشمل ذلك خلط اللغات في المشروع؟
يمكن أن تتخيل هذا للحصول على الفوضى. يعتمد F # على طلب الملف.

هناك شيء سألاحظه هو أن دعم NET Core يعني ضمنيًا دعم F # تمامًا. لذلك إذا كان الهدف ، على سبيل المثال ، دعم .NET Core 3.0 ، فإن دعم F # يأتي مع ذلك. ومع ذلك ، فإن هذا لا يعني مستوى من دعم الأدوات ، مثل المصممين.

إذا كانت سجلات F # (القابلة للتغيير) XAML سهلة التجليد وكان لدينا بعض الأمثلة ، مع تضمين أوامر واجهة المستخدم ، أعتقد أن المصمم سيعمل بنفس الأدوات من C # ، وسيكون لدينا "الكود خلف" + كائنات البيانات في F # .

على سبيل المثال: كيفية عمل واجهة المستخدم الرسومية WinUI لشاشة الفاتورة التي تحتوي على العميل ، الفاتورة ، عناصر الفاتورة. مع الأزرار فاتورة جديدة ، حدد العميل ، إضافة / إزالة عناصر الفاتورة.

كيفية نمذجة ذلك في F # وربط البيانات بواجهة المستخدم ، وربط أوامر الزر بوظائف F #؟

TonyHenrique نهج الربط الأصلي في .Net UIs (WPF / UWP / Xamarin / Avalonia) به نقاط ضعف شديدة: الافتقار التام لسلامة النوع ، والتنفيذ الخارق للخرائط ("المحولات") ، والسلاسل السحرية في كل مكان. ليس مناسبًا لـ F #. من الأفضل تجاهل هذه البنية التحتية واستخدام إما الأساليب الوظيفية المعتدلة (الأساليب التفاعلية مثل Gjallarhorn - قد ترى هذه على أنها تطبيقات تم تنفيذها بشكل صحيح للربط) أو مناهج وظيفية متطرفة (Elmish ، على سبيل المثال Fabulous).

من الأفضل استخدام xaml للتصميم فقط ولديك موفر نوع يمنح الوصول إلى كائنات واجهة المستخدم (كما هو الحال في FsXaml لـ WPF).

سيكون موفر نوع WinUI XAML F # أسلوبًا رائعًا لفصل رمز واجهة المستخدم عن الأحداث وكود ربط البيانات.

عند القيام بذلك ، سنتمكن من استخدام محرر WinUI XAML Design Time العادي.

(ما يقلقني في Elmish هو أنه بالنسبة لواجهة المستخدم الكبيرة والمعقدة ، المختلطة داخل الكود ، فإنها تميل إلى أن تبدو مثل كود php spaghetti القديم.
Gjallarhorn لطيف أيضًا. الأمر متروك لفريق F # لاختيار الأفضل لنا)

الآن ، يرجى تحريره باستخدام نموذج فصل مناسب لواجهة المستخدم / رمز ، مع وجود ملف WinUI .xaml وملف .fs مع ، كما قلت ، نافذة بها 3 عناصر مستوى: العميل والفاتورة وعناصر الفاتورة وأزرار إضافة / إزالة العناصر ، على سبيل المثال.

أعتقد أنه مع هذا _Azure Functions F # Project Template_ سيكون من السهل التبديل تمامًا إلى F # في مشاريعي الجديدة.

شيء آخر يمكن القيام به هو السماح بحرف XAML في كود C # / F #.
هذا من شأنه تمكين رمز مثل هذا

let myButton title = <Button Text=title />

وسيبدو مألوفًا لعشاق XAML مثلي ، ويبدو أيضًا مثل رمز React.

لا شكرًا ، أنا راضٍ عن الطريقة الرائعة / الخرافية لإعلان وجهات النظر.

tonyhenrique أنا لا أوافق. ليس الأمر متروكًا لـ MS لتقرير كيفية تطوير واجهات المستخدم في F #. هناك مساحة كافية للعديد من الأساليب ، على الرغم من أنني شخصياً أفضل أسلوب Elmish لأنه يستفيد بشكل كامل من F # بدلاً من الاضطرار إلى العبث بهياكل البيانات القابلة للتغيير في كل مكان.

isaacabraham هل من الممكن استخدام Elmish MVU ، مع WinUI XAML Type Provider ، ولديك إعلان واجهة المستخدم في ملف XAML منفصل؟ سيسمح هذا باستخدام محرر XAML العادي ، ولكن مع ثبات F # وسلامة النوع.

حول قرار MS هذا ، هناك العديد من المزايا. سيكون وجود نموذج F # GUI Visual Studio Project مناسبًا للطريقة المحددة (سواء: ربط السجلات القابلة للتغيير ، أو gjallahorn ، أو elmish بملف XAML منفصل) أمرًا رائعًا.
سأكون مهتمًا جدًا برؤية هذا.

لا يمكنني التعليق على WinUI ولكن لدينا تطبيقات WPF في حل F # خالص يستخدم مصمم VS XAML المدمج + مزود نوع XAML. استخدمنا FSharp.ViewModule على الرغم من أننا ربما نستخدم اليوم مكتبة Elmish WPF.

فيما يتعلق بالقوالب ، لدي مشاعر مختلطة تجاههم. أولاً ، في حين أنها مفيدة كأداة لزيادة التسويق والوعي ، إلا أنها صعبة التغيير وغير مرنة. سيكون الحل الأفضل IMHO هو قالب dotnet و / أو حزمة nuget - شيء يركز بشكل أكبر على الكود بدلاً من اقترانه بـ VS - لقد انتقلنا (أو يجب أن نبتعد) عن IMHO.

يعود هذا أيضًا إلى ما إذا كان هذا قرار "MS" أو شيئًا يقوده المجتمع أم لا. بدلاً من الاعتماد على MS لتقرر كيف يبدو ذلك ، لماذا لا تكون استباقيًا وتخلق شيئًا ما دون الانتظار / الاعتماد على شخص آخر.

شكرا لكmdtaukTonyHenriquecharlesroddieJaggerJocartermp @ Happypig375isaacabraham وغيرها للحصول على تعليقات مدروس الخاص بك على هذه المسألة! أنا أساعد فريق UWP Xaml في تحديد ما إذا كان وكيفية الاستثمار في دعم F #. ما نوع (أنواع) الدعم الذي سيكون أكثر إفادة عند إنشاء تطبيقات F #؟

@ kathyang : بالنسبة لي ، سيكون من المفيد أن يكون لديك قالب مشروع F # WinUI GUI لـ Visual Studio 2019 ، الذي يحتوي على موفر نوع WinUI XAML ، والذي يسمح باستخدام محرر XAML العادي ، ولكن مع وجود رمز F # خلف ، في Gjallarhorn و / أو الميش.

kathyang الشيء الأساسي المطلوب هو السماح بتثبيت UWP عبر حزمة nuget. سيسمح هذا باستخدام عروض UWP من أي لغة .Net.

سيكون العمل على تقديم نوع المساعدة موضع تقدير ولكنه يتطلب بعض المناقشة التفصيلية. من الصعب أن ترى كيف يمكن للمجتمع أن يحافظ على مزودي الأنواع الثلاثة ، خاصةً لأنه حاليًا شخص واحد

TonyHenrique شكرا لإجابتك! سأشاركها مع الفريق كخيار.

charlesroddie هذه نقطة جيدة حول موفري النوع. هل يمكن أن توضح لي - عندما قلت "السماح بتثبيت UWP عبر حزمة nuget. سيسمح هذا باستخدام طرق عرض UWP من أي لغة .Net" ، هل تقصد شيئًا مختلفًا عن هذا ؟

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 # في هذه المناقشة حتى يتم سماع صوتك عندما نعود إلى هذا لاحقًا!