Maui: [Modifié] L'interface utilisateur codée de style MVU est-elle vraiment nécessaire ?

Créé le 29 mai 2020  ·  16Commentaires  ·  Source: dotnet/maui

Je pense que MAUI ne devrait s'en tenir qu'à une seule façon de concevoir l'interface utilisateur, à savoir : XAML

Blazor Syntex va bien, mais MVU me semble un gâchis totalement inutile. Si c'est pour attirer les développeurs de Flutter, s'il vous plaît, laissez-les rester avec Flutter ; NE PAS détruire la beauté de XAML ;

_[Mettre à jour]_
image

Xaml </> blazor

Commentaire le plus utile

@davidortinau comme je l'ai dit dans l'autre fil. Le billet de blog MAUI a créé une confusion massive. Les gens semblent maintenant penser MVU = voir comme code/DSL.
Mais cela est complètement indépendant de ce qu'est MVU. MVU est parfaitement possible avec XAML. Cela n'a rien à voir avec la façon dont vous écrivez la vue.
Il s'agit uniquement de créer un modèle immuable + une fonction de mise à jour qui prend un modèle et un message et construit un nouveau modèle ainsi qu'une fonction de visualisation qui ne mute pas directement le modèle mais envoie de nouvelles commandes (messages) dans la boucle de mise à jour.

Tous les 16 commentaires

Flutter a une page entière dédiée à attirer des personnes de Xamarin.Forms. Vous dites que nous devrions ignorer la concurrence. Vraiment?

Les reliures Blazor sont magnifiques ! Je débute avec eux et ils offrent la simplicité que fait Flutter.

@davidortinau comme je l'ai dit dans l'autre fil. Le billet de blog MAUI a créé une confusion massive. Les gens semblent maintenant penser MVU = voir comme code/DSL.
Mais cela est complètement indépendant de ce qu'est MVU. MVU est parfaitement possible avec XAML. Cela n'a rien à voir avec la façon dont vous écrivez la vue.
Il s'agit uniquement de créer un modèle immuable + une fonction de mise à jour qui prend un modèle et un message et construit un nouveau modèle ainsi qu'une fonction de visualisation qui ne mute pas directement le modèle mais envoie de nouvelles commandes (messages) dans la boucle de mise à jour.

Je pense que MAUI ne devrait s'en tenir qu'à une seule façon de concevoir l'interface utilisateur, à savoir : XAML

Blazor Syntex va bien, mais MVU me semble un gâchis totalement inutile. Si c'est pour attirer les développeurs de Flutter, s'il vous plaît, laissez-les rester avec Flutter ; NE PAS détruire la beauté de XAML ;

Il est destiné aux développeurs C# et .NET.

@sim756

Je pense que MAUI ne devrait s'en tenir qu'à une seule façon de concevoir l'interface utilisateur, à savoir : XAML

Cela n'a jamais été à sens unique. Les interfaces utilisateur basées sur du code sont prises en charge via Xamarin.Forms depuis le début. Rendre cela plus accessible est logique. Et au fait : MVU peut être utilisé facilement avec XAML ( Xamarin.Forms , WPF ).

@Happypig375

Flutter a une page entière dédiée à attirer des personnes de Xamarin.Forms. Vous dites que nous devrions ignorer la concurrence. Vraiment?

Eh bien, nous ferions mieux d'avoir la page " Xamarin pour les développeurs Flutter " !

@rohanbojja

Les reliures Blazor sont magnifiques ! Je débute avec eux et ils offrent la simplicité que fait Flutter.

Tout va bien , sauf cela, et pourquoi je de this n'aime pas Flutter:
image
Image 0

@forki

@davidortinau comme je l'ai dit dans l'autre fil. Le billet de blog MAUI a créé une confusion massive. Les gens semblent maintenant penser MVU = voir comme code/DSL.
Mais cela est complètement indépendant de ce qu'est MVU. MVU est parfaitement possible avec XAML. Cela n'a rien à voir avec la façon dont vous écrivez la vue.
Il s'agit uniquement de créer un modèle immuable + une fonction de mise à jour qui prend un modèle et un message et construit un nouveau modèle ainsi qu'une fonction de visualisation qui ne mute pas directement le modèle mais envoie de nouvelles commandes (messages) dans la boucle de mise à jour.

Je suis vraiment confus !! Merci, vous venez de préciser, le message est catastrophiquement déroutant :
image
Image 1

@saint4eva

Je pense que MAUI ne devrait s'en tenir qu'à une seule façon de concevoir l'interface utilisateur, à savoir : XAML
Blazor Syntex va bien, mais MVU me semble un gâchis totalement inutile. Si c'est pour attirer les développeurs de Flutter, s'il vous plaît, laissez-les rester avec Flutter ; NE PAS détruire la beauté de XAML ;

Il est destiné aux développeurs C# et .NET.

" Il est destiné au développement C# et .NET. ", exactement, il ne devrait pas être influencé par Flutter (je crains que ce ne le soit..).

@aspnetde

@sim756

Je pense que MAUI ne devrait s'en tenir qu'à une seule façon de concevoir l'interface utilisateur, à savoir : XAML

Cela n'a jamais été à sens unique. Les interfaces utilisateur basées sur du code sont prises en charge via Xamarin.Forms depuis le début. Rendre cela plus accessible est logique. Et au fait : MVU peut être utilisé facilement avec XAML ( Xamarin.Forms , WPF ).

Je connais. Parfois, nous écrivons new Button() { .... } , mais ce message ( Image 1 ) m'a dérouté, et bien d'autres, je crois.

@Happypig375

Flutter a une page entière dédiée à attirer des personnes de Xamarin.Forms. Vous dites que nous devrions ignorer la concurrence. Vraiment?

Eh bien, nous ferions mieux d'avoir la page " Xamarin pour les développeurs Flutter " !

MDR. Imaginez une page dédiée aux "Windows Forms pour les développeurs WPF".

XAML n'est qu'un "outil" au-dessus du modèle objet... Vous pouvez utiliser xaml, c#. Vous pouvez concevoir votre application en utilisant MVVM (avec ou sans XAML) ou avec MVU (pour être honnête, les exemples fournis n'étaient pas de "vrais" MVU mais c'est un autre sujet).

Si vous n'aimez pas l'interface utilisateur codée ou l'approche MVU, ignorez-la :) Il n'est pas nécessaire de la repousser.

Je ne pense pas que ce soit juste pour attirer le développeur flutter. Le modèle MVU est à la hausse et est très bien adapté au développement mobile.

De plus, l'interface utilisateur codée est à la hausse... réagissez, flutter, swiftUI, etc... elles gagnent BEAUCOUP en popularité et ne sont pas seulement du battage publicitaire...

@GiampaoloGabba
Je pense que je devrais préciser que je suis moins contre MVU que Coded-UI. Je suis confus par ce message que je crains que l'interface utilisateur codée ne soit le moyen par défaut de développer des interfaces utilisateur (... j'ai peur de perdre XAML).

Eh bien, nous avons .designer.cs , mais nous n'avons pas eu à modifier le code là-bas, même si je suppose que de nombreux développeurs Windows Forms n'ont même jamais vu le contenu des fichiers .designer.cs . Mais ici, nous avons l'éditeur d' interface graphique _capable_ que nous n'avons pas eu à nous soucier du code Coded-UI dans le fichier _.designer.cs_.

Je ferais mieux de modifier le titre de ce numéro.

Ce que je voulais dire:

Que choisirons-nous entre Flutter/Swift/Coded-UI et WPF/XAML avec un éditeur d'interface graphique comme Blend pour Visual Studio ?

@sim756

Je connais. Parfois, nous écrivons un nouveau Button() { .... }

Parfois, les gens écrivent des applications XF entières sans toucher à XAML - et ils en sont ravis ;-).

@sim756

Je connais. Parfois, nous écrivons un nouveau Button() { .... }

Parfois, les gens écrivent des applications XF entières sans toucher à XAML - et ils en sont ravis ;-).

@aspnetde

Je suis surpris..!! ??

Cependant, pas pour eux, mais pour des gens comme moi, qui veulent Blend pour Xamarin/MAUI, c'est mécontent :

Éditeur de mouvement Android Studio

https://developer.android.com/studio/write/motion-editor

image

@sim756 Je me demande si vous souhaitez toujours bénéficier de la prise en charge de blend une fois que vous avez travaillé dans un système avec un rechargement à chaud fonctionnant correctement. Habituellement, les gens préfèrent beaucoup ça

Venant d'un contexte XAML / Blend, mes premières réflexions sur l'interface utilisateur dans le code étaient de reculer, mais une fois que je l'ai essayé, j'ai vu de nombreux avantages que je n'avais tout simplement pas envisagés. La suppression du besoin de fonctionnalités telles que les convertisseurs, les ressources et similaires m'ont fait croire aux interfaces utilisateur axées sur le code.

Eh bien, nous avons .designer.cs, mais nous n'avons pas eu à modifier le code là-bas, même je suppose que de nombreux développeurs Windows Forms n'ont même jamais vu le contenu des fichiers .designer.cs.

@sim756 - bien qu'un concepteur capable ressemble à un excellent outil de productivité, si vous êtes dans le

En ce qui concerne XAML, @dsyme parle de la dépendance à l'égard de l'outillage lourd dans cette présentation

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

adojck picture adojck  ·  15Commentaires

Amine-Smahi picture Amine-Smahi  ·  3Commentaires

Joshua-Ashton picture Joshua-Ashton  ·  9Commentaires

UriHerrera picture UriHerrera  ·  3Commentaires

Suplanus picture Suplanus  ·  4Commentaires