#736의 중복

#736의 중복

로드맵 문서에 추가하기 위한 PR입니다. 이 문제도 추적할 수 있기를 바랍니다. 😊

@jesbis 충분합니다. F#이 많을수록 좋습니다. 사람들을 행복하게 하고 WinUI 3.0이 가능한 한 많은 Microsoft 개발 플랫폼을 포함하도록 합니다. 😀

F# 두 가지 중요한 접근 방식이 있습니다.
1) F#(변경 가능) 레코드를 XAML 바인딩/Gjallarhorn에 적합하게 만듭니다.

2) 엘미쉬 스타일

둘 다 지원될 수 있으며 샘플이 있습니다. 아마도 미래에는 1가지 추세만 더 많이 사용될 것입니다.

.NET 5의 UI용 F# 프로젝트 템플릿이 필요합니다.

단일 프로젝트에서 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 앱에서 Visual Studio F# 도구 사용 활성화 | 해야하다

이것을 명확히 할 수 있습니까? "Xaml"은 현재 매우 혼란스럽습니다. "Xaml"이 마크업 언어를 의미하는 경우 유형 공급자로 해결해야 할 복잡한 문제일 수 있습니다(아래 링크 참조). 그러나 "Xaml 앱"이 "WinUI 앱"을 의미하는 경우 이는 1의 일부일 뿐입니다.

1. 부분 클래스에서 Xaml 페이지 코드 숨김에 F# 사용 활성화 | 할 수 있었다

https://github.com/dotnet/wpf/issues/162 에서 부분 클래스/XAML 유형 공급자/BAML 컴파일에 대한 토론을 참조

현재 F#에서는 UWP UI를 빌드할 수 없습니다. 전체 UI 레이어를 제공함으로써(Win UI 3.0에서 계획된 대로) 이것은 최소한 가능하게 될 것이며, 저는 그것을 참을성 있게 기대하고 있습니다.

1: 기존 xlang 지원이 충분합니까(새 샘플 포함)?
개인적으로 괜찮습니다. 기본 템플릿이 좋을 것입니다.

2: 어떤 유형의 템플릿이나 샘플이 유용할까요?
기본 샘플은 좋은 출발점이 될 것입니다.

3: 여기에 지원하는 Xaml 페이지 코드 숨김 파일이 포함되어야 합니까?
많은 F# 개발자가 UI 구축을 위해 MVU 접근 방식을 선호할 것이라고 생각합니다.
일반적인 XAML + MVVM은 가변성에 의존합니다. UWP에 특정한 Fabolous 와 같은 것이 큰 판매 포인트가 될 것입니다(제 생각에는).
기본적으로 MVU 추상화와 같은 Elm / React가 더 일반적입니다.

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/Avalonia)의 기본 바인딩 접근 방식에는 심각한 약점이 있습니다. 유형 안전성이 완전히 결여되고 맵("변환기")의 해킹 구현, 도처에 있는 마법 문자열입니다. F#에 적합하지 않습니다. 이 인프라를 무시하고 중간 수준의 기능적 접근 방식(Gjallarhorn과 같은 반응적 접근 방식 - 바인딩 구현이 제대로 수행된 것으로 볼 수 있음) 또는 극단적인 기능적 접근 방식(Elmish, 예: Fabulous)을 사용하는 것이 좋습니다.

디자인에만 xaml을 사용하고 형식 공급자가 UI 개체에 대한 액세스 권한을 부여하도록 하는 것이 좋습니다(WPF용 FsXaml에서와 같이).

WinUI XAML F# 유형 공급자 는 이벤트 및 데이터 바인딩 코드에서 UI 코드를 분리하는 멋진 접근 방식입니다.

이렇게 하면 일반 WinUI XAML 디자인 시간 편집기를 사용할 수 있습니다.

(elmish에서 나를 걱정시키는 것은 코드 내부에 혼합된 크고 복잡한 UI의 경우 오래된 PHP 스파게티 코드처럼 보이는 경향이 있다는 것입니다.
Gjallarhorn 도 좋습니다. 우리에게 가장 적합한 것을 선택하는 것은 F# 팀의 몫입니다)

이제 WinUI .xaml 파일과 .fs 파일이 있는 적절한 UI/코드 분리 샘플과 함께 릴리스하십시오. 이 파일에는 고객, 송장, 송장 항목 및 항목 추가/제거 버튼의 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 WinUI XAML 유형 공급자와 함께 Elmish MVU를 사용할 수 있으며 별도의 XAML 파일에 UI 선언이 있습니까? 이렇게 하면 일반 XAML 편집기를 사용할 수 있지만 F#의 불변성과 형식 안전성이 있습니다.

MS가 이것을 결정하는 데에는 많은 이점이 있습니다. 선택한 방식(변경 가능한 레코드 바인딩, gjallahorn 또는 elmish를 별도의 XAML 파일로 바인딩)에 대한 적절한 F# GUI Visual Studio 프로젝트 템플릿이 있으면 굉장할 것입니다.
나는 이것을 보는 것에 매우 흥미를 가질 것입니다.

WinUI에 대해서는 언급할 수 없지만 기본 제공 VS XAML 디자이너 + XAML 형식 공급자를 사용하는 순수 F# 솔루션에 WPF 앱이 있습니다. 우리는 아마도 오늘날 Elmish WPF 라이브러리를 사용할 것이지만 FSharp.ViewModule을 사용했습니다.

템플릿에 관해서는 만감이 교차합니다. 첫째, 마케팅 및 인지도를 높이는 도구로 유용하지만 변경하기 어렵고 유연하지 않습니다. 더 나은 솔루션 IMHO는 dotnet 템플릿 및/또는 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 Type Provider 가 포함되어 있어 일반 XAML 편집기를 사용할 수 있지만 Gjallarhorn에서 F# 코드 비하인드가 있습니다. 및/또는 엘미쉬.

@kathyang 필요한 기본 사항은 nuget 패키지를 통해 UWP를 설치할 수 있도록 하는 것입니다. 이렇게 하면 모든 .Net 언어에서 UWP 보기를 사용할 수 있습니다.

도움 유형 공급자를 만드는 작업은 감사할 것이지만 몇 가지 자세한 논의가 필요합니다. 커뮤니티가 3가지 유형 공급자를 유지 관리하는 방법을 확인하는 것은 어렵습니다. 특히 현재 @ReedCopsey 한 명이 FsXaml WPF 유형 공급자를 사용하여 이 작업을 수행하고 있기 때문입니다. 별도로 개발된 UWP 형식 공급자는 가까운 장래에 작업을 정당화할 용도가 없습니다. 다양한 Xaml 플레이버를 통합할 수 있는 경우 동일한 구조를 공유하는 WPF/UWP/XF에 대해 형식 공급자를 만들 수 있습니다. 이러한 형식 공급자는 F# 사용에 동일한 우선 순위가 없기 때문에 가능한 모든 Xaml에 대한 지원이 필요하지 않습니다(C# 개발자는 종종 Xaml의 코드와 유사한 기능이 필요한 View 프로젝트에서 코드 없음을 옹호함).

@TonyHenrique 답변 감사합니다! 옵션으로 팀과 공유하겠습니다.

@charlesroddie 유형 제공자에 대한 좋은 지적입니다. 당신은 나를 위해 명확하게 할 수 - 당신이 말한 때부터 당신에게 평균 뭔가 다른 작업을 수행 "UWP가 nuget 패키지를 통해 설치 될 수 있도록이 모든 .NET 언어에서 UWP 뷰의 사용을 허용합니다." 이 ?

@kathyang Microsoft.UI.Xaml은 올바른 유형입니다(이름 지정 제외). 이것이 모든 .Net 프로젝트에서 작동하도록 만들 수 있고 모든 UWP View 클래스를 포함하는 경우 F# 지원의 주요 단계가 됩니다.

현재 Microsoft.UI.Xaml은 특수 UWP 프로젝트에서 작동하지만(F#에는 해당 프로젝트가 없음) .Net Standard 프로젝트( The namespace UI is not defined )에서는 작동하지 않습니다.

유익한 지식을 주신 모든 분들께 감사드립니다! 우리 팀은 이에 대해 논의했으며 WinUI 2.2 및 WinUI 3 및 이 릴리스에 포함될 많은 중요한 기능에 초점을 맞추고 있기 때문에 현재로서는 이에 투자할 리소스가 없다고 결정했습니다. 일단 WinUI 3가 출시되고 XAML 프레임워크가 OS에서 분리되면 우리와 커뮤니티는 이를 함께 재검토할 수 있습니다. 이 문제에 needs-winui-3 레이블을 추가하고 있습니다. 이 토론에서 F# 지원에 대한 의견을 계속 공유하여 나중에 이 문제로 돌아올 때 여러분의 목소리를 들을 수 있도록 하십시오!