Duplicado de # 736

Duplicado de # 736

Eso es un PR para agregarlo al documento de la hoja de ruta; nos gustaría tener un problema para rastrear esto también 😊

@jesbis Bastante justo. Cuanto más F #, mejor. Mantenga a la gente feliz y asegúrese de que WinUI 3.0 abarque la mayor cantidad posible de plataformas de desarrollo de Microsoft. 😀

F # Veo dos enfoques importantes:
1) Hacer que los registros XAML de F # (mutables) sean compatibles con la vinculación / Gjallarhorn;

2) estilo olmo

Ambos podrían ser compatibles y tener muestras. Quizás en el futuro solo se use más una tendencia.

Necesitaremos las plantillas de proyecto de F # para la interfaz de usuario en .NET 5

Sería genial mezclar y combinar F # y C # en un solo proyecto. Use F # para cosas de datos y C # para UI / Commands.

Solo F # + GUI debería funcionar perfectamente, de forma independiente.
La única solución de AF # sería compatible, por ejemplo, con consumir un registro de la función Azure + F # y vincularlo de dos formas a un TextBox, por ejemplo.

¡Una interfaz de usuario / comando en F # se vería muy simple y genial!

@jesbis

1. Habilitar el uso de F # para la lógica empresarial de la aplicación | Debe
2. Habilite la mezcla y coincidencia de idiomas (por ejemplo, F # para datos y lógica, C # para UI + enlaces) | Podría

Estos parecen iguales y están implícitos al permitir que los proyectos de C # que hacen referencia a WinUI también hagan referencia a cualquier proyecto .Net. Eso debería ser un hecho (asumiendo que puede acceder a WinUI instalando un paquete nuget).

(Pero si 5. significa mezclar y hacer coincidir idiomas dentro del mismo proyecto , eso no es posible debido a las diferencias de orden entre C # y F #).

1. Habilitar el uso de herramientas de Visual Studio F # con aplicaciones Xaml | Debe

¿Puedes aclarar esto? "Xaml" es muy confuso en este momento. Si "Xaml" hace referencia al lenguaje de marcado, entonces es un problema complejo que posiblemente deba resolverse con un proveedor de tipos (consulte el enlace a continuación). Pero si "aplicaciones Xaml" significa "aplicaciones WinUI", esto es solo una parte de 1.

1. Habilite el uso de F # para el código de página Xaml detrás de clases parciales | Podría

Consulte la discusión sobre clases parciales / proveedores de tipo XAML / compilación BAML aquí: https://github.com/dotnet/wpf/issues/162 .

Actualmente, no es posible crear interfaces de usuario para UWP en F #. Al enviar toda la capa de la interfaz de usuario (como se planeó en Win UI 3.0), esto al menos será posible, y lo estoy esperando con impaciencia.

1: ¿Es suficiente la compatibilidad con xlang existente (con nuevas muestras)?
Personalmente de acuerdo con eso, las plantillas básicas estarían bien.

2: ¿Qué tipos de plantillas o muestras serían útiles?
Las muestras básicas serían un buen punto de partida.

3: ¿Debería esto incluir la compatibilidad con archivos de código subyacente de página Xaml?
Creo que muchos desarrolladores de F # preferirían un enfoque MVU para crear interfaces de usuario.
XAML + MVVM típico se basa en la mutabilidad, algo como Fabolous específico para UWP sería un gran punto de venta (en mi opinión).
Básicamente, Elm / React como abstracciones MVU para ser más generales.

4: ¿Podría / debería incluir la mezcla de idiomas en un proyecto?
Puedo imaginar que esto se ensucie. F # depende del orden de los archivos.

Algo que señalaré es que admitir .NET Core por completo implica admitir F #. Entonces, si un objetivo es, por ejemplo, admitir .NET Core 3.0, entonces la compatibilidad con F # viene con eso. Sin embargo, esto _no_ implica un nivel de soporte de herramientas, como los diseñadores.

Si los registros XAML de F # (mutables) fueran compatibles con la vinculación y tuviéramos algún ejemplo, con comandos de interfaz de usuario incluidos, creo que el diseñador trabajaría con las mismas herramientas de C #, y tendríamos el "código subyacente" + objetos de datos en F # .

Por ejemplo: Cómo hacer una GUI de WinUI de una pantalla de Factura que tiene Cliente, Factura, Elementos de la factura. Con los botones Nueva factura, seleccione cliente, Agregar o quitar elementos de la factura.

¿Cómo modelarlo en F # y vincular los datos a la interfaz de usuario, y vincular los comandos del botón a las funciones de F #?

@TonyHenrique El enfoque de enlace nativo en .Net UI (WPF / UWP / Xamarin / Avalonia) tiene graves debilidades: falta total de seguridad de tipos, implementación pirata de mapas ("convertidores"), cadenas mágicas en todas partes. No es un buen ajuste para F #. Es mejor ignorar esta infraestructura y utilizar enfoques funcionales moderados (enfoques reactivos como Gjallarhorn; es posible que los vea como implementaciones de enlace hechas correctamente) o enfoques funcionales extremos (Elmish, por ejemplo, Fabulous).

Es mejor usar xaml únicamente para el diseño y tener un proveedor de tipos que brinde acceso a los objetos de la interfaz de usuario (como en FsXaml para WPF).

Un proveedor de tipo WinUI XAML F # sería un enfoque interesante para separar el código de la interfaz de usuario de los eventos y el código de enlace de datos.

Al hacer esto, podremos usar el editor WinUI XAML Design Time normal.

(Lo que me preocupa en elmish es que para una interfaz de usuario grande y compleja, mezclada dentro del código, tiende a parecerse al antiguo código php spaghetti.
Gjallarhorn también es agradable. Depende del equipo de F # elegir lo mejor para nosotros)

Ahora, libérelo con una muestra adecuada de separación de UI / código, con el archivo WinUI .xaml y un archivo .fs con, como dije, una ventana con elementos de 3 niveles: cliente, factura, elementos de factura y botones de agregar / eliminar elementos , por ejemplo.

Creo que con esto y la _Plantilla de proyecto de F # de funciones azure_ será fácil cambiar completamente a F # en mis nuevos proyectos.

Otra cosa que se podría hacer es permitir literales XAML en el código C # / F #.
Esto habilitaría un código como este

let myButton title = <Button Text=title />

y parecería familiar para los fanáticos de XAML como yo, y también se parece al código de React.

No gracias, estoy satisfecho con la forma Fabulous / Fable de declarar vistas.

@tonyhenrique No estoy de acuerdo. No depende de MS decidir cómo debemos desarrollar las IU en F #. Hay espacio suficiente para varios enfoques, aunque personalmente prefiero el estilo Elmish porque aprovecha al máximo F # en lugar de tener que jugar con estructuras de datos mutables en todas partes.

@isaacabraham ¿Es posible usar Elmish MVU, con un proveedor de tipo XAML de WinUI y tener una declaración de la interfaz de usuario en un archivo XAML separado? Esto permitiría usar el editor XAML normal, pero con la inmutabilidad y seguridad de tipos de F #.

Acerca de la decisión de MS sobre esto, hay muchas ventajas. Tener una plantilla de proyecto de Visual Studio F # GUI adecuada para la forma seleccionada (ya sea: vincular registros mutables, gjallahorn o elmish con un archivo XAML separado) sería increíble.
Me interesaría mucho ver esto.

No puedo comentar sobre WinUI, pero tenemos aplicaciones WPF en una solución F # pura que usa el diseñador VS XAML integrado + el proveedor de tipos XAML. Usamos FSharp.ViewModule aunque probablemente hoy usemos la biblioteca Elmish WPF.

Con respecto a las plantillas, tengo sentimientos encontrados sobre ellas. En primer lugar, si bien son útiles como herramienta para aumentar el marketing y la conciencia, son difíciles de cambiar e inflexibles. En mi humilde opinión, una mejor solución sería una plantilla dotnet y / o un paquete nuget, algo más centrado en el código en lugar de estar acoplado a VS, hemos avanzado (o deberíamos alejarnos) de eso en mi humilde opinión.

Esto también se remonta a si se trata de una decisión de "EM" o algo que sea liderado por la comunidad o no. En lugar de depender de la EM para decidir cómo se ve esto, ¿por qué no ser proactivo y crear algo sin esperar o depender de otra persona?

¡Gracias @mdtauk @TonyHenrique @charlesroddie @JaggerJo @cartermp @ Happypig375 @isaacabraham y otros por sus reflexivos comentarios sobre este tema! Estoy ayudando al equipo de UWP Xaml a determinar si invertir en el soporte de F # y cómo hacerlo. ¿Qué tipo de soporte sería más útil al crear aplicaciones de F #?

@kathyang : Para mí, lo más útil sería tener la plantilla de proyecto F # WinUI GUI para Visual Studio 2019 , que tiene un proveedor de tipo WinUI XAML , que permite usar el editor XAML normal, pero con el código F # subyacente, en Gjallarhorn y / o Elmish.

@kathyang Lo básico que se necesita es permitir que UWP se instale a través de un paquete nuget. Esto permitirá el uso de vistas de UWP desde cualquier idioma .Net.

Se agradecería el trabajo para crear proveedores de tipos de ayuda, pero requeriría una discusión detallada. Es difícil ver cómo la comunidad puede mantener 3 proveedores de tipos, especialmente porque actualmente es una persona @ReedCopsey haciendo esto (con el proveedor de tipos FsXaml WPF). Un proveedor de tipo UWP desarrollado por separado no tendría el uso para justificar el trabajo en un futuro próximo. Si pudiera haber alguna consolidación de los distintos tipos de Xaml, entonces se podrían crear proveedores de tipos para WPF / UWP / XF que compartan la misma estructura. Estos proveedores de tipos no necesitarían tener soporte para todos los Xaml posibles, ya que el uso de F # no tiene las mismas prioridades (los desarrolladores de C # a menudo recomiendan que no haya código en los proyectos de View, lo que luego requiere características similares al código en Xaml).

@TonyHenrique ¡ Gracias por tu respuesta! Lo compartiré con el equipo como una opción.

@charlesroddie Ese es un buen punto sobre los proveedores de tipos. ¿Podrías aclararme: cuando dijiste "permitir que UWP se instale a través de un paquete nuget. Esto permitirá el uso de vistas de UWP desde cualquier lenguaje .Net", te refieres a algo diferente a esto ?

@kathyang Microsoft.UI.Xaml es el tipo correcto de cosas (dejando de lado el nombre). Si se puede hacer que funcione en cualquier proyecto .Net y contiene todas las clases de Vista de UWP, entonces sería el paso principal en la compatibilidad con F #.

Actualmente, Microsoft.UI.Xaml funciona en proyectos especiales de UWP (y no existe tal proyecto para F #), pero no en proyectos .Net Standard ( The namespace UI is not defined ).

¡Gracias a todos por sus valiosos conocimientos! Nuestro equipo ha discutido esto y ha determinado que no tenemos los recursos para invertir en esto en este momento, ya que nos estamos enfocando en WinUI 2.2 y WinUI 3 y muchas características importantes en estas versiones. Una vez que se envía WinUI 3 y el marco XAML se desacopla del sistema operativo, nosotros y la comunidad podemos revisar esto juntos. Estoy agregando la etiqueta need-winui-3 a este problema y, por favor, continúe compartiendo sus comentarios sobre el soporte de F # en esta discusión para que se escuche su voz cuando volvamos a esto más adelante.