Duplicado de # 736

Duplicado de # 736

Isso é um PR para adicioná-lo ao documento do roteiro - gostaríamos de ter um problema para rastrear isso também 😊

@jesbis Muito justo. Quanto mais F #, melhor. Mantenha as pessoas felizes e garanta que o WinUI 3.0 englobe o máximo possível de plataformas de desenvolvimento da Microsoft. 😀

F # vejo duas abordagens importantes:
1) Tornar os registros F # (mutáveis) XAML Binding Friendly / Gjallarhorn;

2) Estilo Elmish

Ambos podem ser suportados e têm amostras. Talvez no futuro apenas 1 tendência se torne mais usada.

Precisaremos dos modelos de projeto F # para interface do usuário no .NET 5

Seria ótimo misturar e combinar F # e C # em um único projeto. Use F # para dados e C # para IU / Comando.

Apenas F # + GUI deve funcionar perfeitamente, autônomo.
A solução AF # apenas seria compatível, por exemplo, com o consumo de um registro do Azure Function + F # e vinculá-lo de duas vias a um TextBox, por exemplo.

Uma IU / Comando em F # pareceria muito simples e legal!

@jesbis

1. Habilite o uso de F # para a lógica de negócios do aplicativo | Deve
2. Habilite a combinação e correspondência de linguagens (por exemplo, F # para dados e lógica, C # para UI + ligações) | Poderia

Eles parecem iguais e estão implícitos ao permitir que os projetos C # que fazem referência ao WinUI também façam referência a quaisquer projetos .Net. Isso deve ser um dado adquirido (assumindo que você pode acessar o WinUI instalando um pacote nuget).

(Mas se 5. significa misturar e combinar linguagens dentro do mesmo projeto , isso não é possível devido às diferenças de ordenação entre C # e F #.)

1. Habilite o uso de ferramentas do Visual Studio F # com aplicativos Xaml | Deve

Você pode esclarecer isso? "Xaml" é muito confuso no momento. Se "Xaml" significa a linguagem de marcação, então é um problema complexo que pode ser resolvido com um provedor de tipo (veja o link abaixo). Mas se "aplicativos Xaml" significa "aplicativos WinUI", isso é apenas parte de 1.

1. Habilite o uso de F # para a página Xaml codebehind classes parciais | Poderia

Consulte a discussão sobre classes parciais / provedores de tipo XAML / compilação BAML aqui: https://github.com/dotnet/wpf/issues/162 .

Atualmente não é possível construir interfaces de usuário UWP em F #. Ao enviar toda a camada de interface do usuário (conforme planejado no Win UI 3.0), isso pelo menos será possível, e estou ansioso para isso.

1: O suporte xlang existente é suficiente (com novas amostras)?
Pessoalmente ok com isso, modelos básicos seriam bons.

2: Que tipos de modelos ou amostras seriam úteis?
Amostras básicas seriam um bom ponto de partida.

3: Isso deve incluir o suporte a arquivos codebehind de páginas Xaml?
Acho que muitos desenvolvedores de F # prefeririam uma abordagem MVU para construir interfaces de usuário.
XAML + MVVM típico depende de mutabilidade, algo como Fabolous específico para UWP seria um grande ponto de venda (na minha opinião).
Basicamente, o Elm / React gosta das abstrações MVU para ser mais geral.

4: Isso poderia / deveria incluir a mistura de idiomas em um projeto?
Posso imaginar que isso fique bagunçado. F # depende da ordem do arquivo.

Algo que observarei é que o suporte ao .NET Core implica completamente no suporte a F #. Portanto, se uma meta é, por exemplo, oferecer suporte ao .NET Core 3.0, então o suporte F # vem com isso. No entanto, isso _não_ implica um nível de suporte de ferramentas, como designers.

Se o F # (mutável) Records XAML fosse Binding Friendly e tivéssemos algum exemplo, com UI Commands incluídos, acho que o Designer trabalharia com as mesmas ferramentas do C #, e teríamos o "código por trás" + objetos de dados em F # .

Por exemplo: Como fazer uma GUI WinUI de uma tela de fatura que contém Cliente, Fatura, Itens de fatura. Com os botões Nova Fatura, selecione cliente, Adicionar / Remover Itens da Fatura.

Como modelá-lo em F # e vincular os dados à IU e vincular os comandos de botão às funções F #?

@TonyHenrique A abordagem de ligação nativa em .Net UIs (WPF / UWP / Xamarin / Avalonia) tem graves deficiências: completa falta de segurança de tipo, implementação hacky de mapas ("conversores"), strings mágicas em todos os lugares. Não é um bom ajuste para F #. É melhor ignorar essa infraestrutura e usar abordagens funcionais moderadas (abordagens reativas como Gjallarhorn - você pode vê-las como implementações de ligação feitas corretamente) ou abordagens funcionais extremas (Elmish, por exemplo, Fabulous).

É melhor usar o xaml puramente para design e ter um provedor de tipo que dê acesso aos objetos da interface do usuário (como em FsXaml para WPF).

Um provedor do tipo WinUI XAML F # seria uma abordagem interessante para separar o código da IU dos eventos e do código de vinculação de dados.

Fazendo isso, poderemos usar o editor WinUI XAML Design Time normal.

(O que me preocupa em elmish é que, para interfaces de usuário grandes e complexas, misturadas dentro do código, tende a se parecer com um código antigo de php spaghetti.
Gjallarhorn também é bom. Cabe à equipe F # escolher o melhor para nós)

Agora, por favor, libere-o com uma amostra de separação de IU / código adequada, tendo o arquivo WinUI .xaml e um arquivo .fs com, como eu disse, uma janela com 3 itens de nível: cliente, fatura, itens de fatura e botões de adicionar / remover itens , por exemplo.

Acho que com isso e com o _Modelo de projeto F # das funções do Azure_ será fácil mudar completamente para o F # em meus novos projetos.

Outra coisa que pode ser feita é permitir literais XAML em código C # / F #.
Isso habilitaria um código como este

let myButton title = <Button Text=title />

e pareceria familiar para fãs de XAML como eu e também se pareceria com o código React.

Não, obrigado, estou satisfeito com a maneira Fabulous / Fable de declarar pontos de vista.

@tonyhenrique eu discordo. Não cabe à MS decidir como devemos desenvolver UIs em F #. Há espaço suficiente para várias abordagens, embora eu pessoalmente prefira o estilo Elmish porque ele aproveita todas as vantagens do F # em vez de ter que mexer com estruturas de dados mutáveis ​​em todos os lugares.

@isaacabraham É possível usar Elmish MVU, com um WinUI XAML Type Provider e ter uma declaração de IU em um arquivo XAML separado? Isso permitiria usar o editor XAML regular, mas com a imutabilidade e a segurança de tipo do F #.

Sobre a MS decidir isso, há muitas vantagens. Ter um modelo de projeto F # GUI Visual Studio adequado para a maneira selecionada (seja: vincular registros mutáveis, gjallahorn ou elmish com arquivo XAML separado) seria incrível.
Eu estaria muito interessado em ver isso.

Não posso comentar sobre o WinUI, mas temos aplicativos WPF em uma solução F # pura que usa o designer VS XAML integrado + o provedor de tipo XAML. Usamos FSharp.ViewModule, embora provavelmente hoje usemos a biblioteca Elmish WPF.

Em relação aos modelos, tenho sentimentos confusos sobre eles. Em primeiro lugar, embora sejam úteis como ferramenta para aumentar o marketing e a conscientização, são difíceis de mudar e inflexíveis. Uma solução melhor IMHO seria um modelo dotnet e / ou pacote nuget - algo mais focado no código ao invés de ser acoplado ao VS - nós mudamos (ou deveríamos estar nos afastando) daquele IMHO.

Isso também nos leva a saber se essa é uma decisão de "EM" ou algo liderado pela comunidade ou não. Em vez de confiar na MS para decidir como isso se parece, por que não ser proativo e criar algo sem esperar / depender de outra pessoa.

Obrigado @mdtauk @TonyHenrique @charlesroddie @JaggerJo @cartermp @ Happypig375 @isaacabraham e outros para os seus comentários pensativo sobre esta questão! Estou ajudando a equipe UWP Xaml a determinar se e como investir no suporte do F #. Que tipo (s) de suporte seriam mais úteis ao criar aplicativos F #?

@kathyang : Para mim, o mais útil seria ter o modelo de projeto F # WinUI GUI para Visual Studio 2019 , que tem um WinUI XAML Type Provider , que permite usar o editor XAML regular, mas tendo o F # Code Behind, em Gjallarhorn e / ou Elmish.

@kathyang O básico necessário é permitir que o UWP seja instalado por meio de um pacote nuget. Isso permitirá o uso de visualizações UWP de qualquer idioma .Net.

O trabalho para fazer provedores de tipo de ajuda seria apreciado, mas exigiria alguma discussão detalhada. É difícil ver como a comunidade pode manter 3 provedores de tipo, especialmente porque atualmente é uma pessoa @ReedCopsey fazendo isso (com o provedor de tipo WPF FsXaml). Um provedor de tipo UWP desenvolvido separadamente não teria o uso para justificar o trabalho em um futuro próximo. Se pudesse haver alguma consolidação dos vários tipos de Xaml, os provedores de tipo poderiam ser feitos para WPF / UWP / XF que compartilham a mesma estrutura. Esses provedores de tipo não precisariam ter suporte para todos os Xaml possíveis, já que o uso do F # não tem as mesmas prioridades (os desenvolvedores C # geralmente não defendem nenhum código em projetos de visualização, o que requer recursos semelhantes aos de código no Xaml).

@TonyHenrique Obrigado pela sua resposta! Estarei compartilhando com a equipe como uma opção.

@charlesroddie Esse é um bom ponto sobre os provedores de tipo. Você poderia esclarecer para mim - quando disse "permitir que UWP seja instalado por meio de um pacote nuget. Isso permitirá o uso de visualizações UWP de qualquer idioma .Net", você quer dizer algo diferente disso ?

@kathyang Microsoft.UI.Xaml é o tipo certo de coisa (nomenclatura à parte). Se isso puder funcionar em qualquer projeto .Net e contiver todas as classes UWP View, então essa seria a etapa principal no suporte a F #.

Atualmente Microsoft.UI.Xaml funciona em projetos UWP especiais (e não existe tal projeto para F #), mas não em projetos .Net Standard ( The namespace UI is not defined ).

Obrigado a todos pelo seu conhecimento útil! Nossa equipe discutiu isso e determinou que não temos os recursos para investir nisso agora, pois estamos nos concentrando no WinUI 2.2 e WinUI 3 e em muitos recursos importantes incluídos nessas versões. Depois que o WinUI 3 for lançado e a estrutura XAML for desacoplada do sistema operacional, nós e a comunidade podemos revisitar isso juntos. Estou adicionando o rótulo needs-winui-3 neste problema e continue a compartilhar seus comentários sobre o suporte F # nesta discussão para que sua opinião seja ouvida quando voltarmos a esse assunto mais tarde!