Maui: MVU ist möglicherweise nicht das, was Sie denken

Danke @aspnetde , ich hoffe, Sie werden uns bei der Umsetzung dieser Idee in den nächsten 18 Monaten oder so begleiten. Angesichts Ihrer Erfahrung mit MVU gehe ich davon aus, dass Sie viel dazu beitragen werden.

Ich denke, es ist zu früh, um zu sagen, ob .NET MAUI MVU ist oder nicht, da wir es noch nicht entwickelt haben . :)

Ja, wir haben einen Prototyp. Ja, es ist vom Comet-Experiment inspiriert. Und ja, wir wissen, dass es Bedenken gibt, dass das, was wir bisher gezeigt haben, nicht jedermanns Definition von MVU entspricht.

Ich hoffe, dass wir zusammenarbeiten können! Wenn das, was wir am Ende entwerfen und versenden, ein anderes Etikett verdient, stimme ich zu, dass wir ihm eines geben sollten.

Wie würden Sie C# MVU in .NET MAUI erwarten?

Welche neuen Sprachfunktionen würden Sie ggf. für erforderlich halten?

Könnte/sollten wir in Betracht ziehen, Fabulous zu integrieren und/oder welche Muster macht es Sinn, C# und F# gemeinsam zu machen, und was sollte anders sein?

Wie würden Sie C# MVU in .NET MAUI erwarten?

Haben Sie schon einmal gehört, dass jemand C# MVC oder C# MVVM sagt? _Model-View-Update_ aka _The Elm Architecture_ ist ein wohldefiniertes Architekturmuster, keine sprachabhängige Implementierung.

Welche neuen Sprachfunktionen würden Sie ggf. für erforderlich halten?

• Während Union-Typen dazu beitragen würden, die Definition von Nachrichten massiv zu vereinfachen, kann dies über Schnittstellen/abstrakte Klassen und eine Unterklasse pro Nachricht erfolgen, obwohl das Schreiben etwas mehr Boilerplate-Code erfordert.
• Um Nachrichten zu verarbeiten, ist ein Mustervergleich hilfreich, wenn er nicht benötigt wird. Ich denke, der aktuelle Zustand der C#-Switch-Ausdrücke ist dafür bereits gut genug, da die Form der Nachrichten einfach sein wird.
• Zu guter Letzt ist das wichtigste Feature, das ich sehe, standardmäßig die Unveränderlichkeit und aktivierte strukturelle Gleichheitsvergleiche. Soweit ich mich an den aktuellen Vorschlag von Datensätzen in C# 9 (auch bekannt als Datenklassen) erinnere, werden diese genau das liefern.

Daher wäre C# 9 zwar immer noch lauter als F#, aber aus meiner aktuellen Sicht gut geeignet.

Könnte/sollten wir in Betracht ziehen, Fabulous zu integrieren und/oder welche Muster macht es Sinn, C# und F# gemeinsam zu machen, und was sollte anders sein?

Wie oben geschrieben, sollte der Gesamtansatz nichts besonders sprachspezifisches enthalten, da MVU selbst nur der Architekturstil oder das App-Modell ist, wie Sie es nennen.

@TimLariviere Hat in Vorschläge gemacht, um Fabulous voranzubringen , was auch Ideen zu einer SwiftUI-ähnlichen DSL enthält. Vielleicht möchten Sie auch dort vorbeischauen und/oder mitmachen.

Übrigens: Ich habe letztes Jahr einen 1:1-Vergleich von XF + C# + MVVM und XF + F# + MVU gemacht, die Ergebnisse gibt es hier – inklusive Quellcode.

Ich denke, es ist zu früh, um zu sagen, ob .NET MAUI MVU ist oder nicht

Es geht nicht darum, ob MAUI am Ende MVU wird. Es geht um das Beispiel im Ankündigungsblog, das in der Community bereits so viel Verwirrung gestiftet hat. Grundsätzlich muss ich davon ausgehen, dass sich die Autoren noch nicht wirklich mit MVU beschäftigt haben. Wenn man über "C# MVU" spricht, wird dies nicht besser.

Ich stimme @aspnetde und @forki zu , hier liegt das Problem in der Kommunikation.

Ich denke, keiner von uns argumentiert, die von Kometen inspirierte C# DSL für MAUI/XF fallen zu lassen oder zu ändern, aber selbst wenn wir nehmen, was bisher damit gemacht wurde, verwendet dies immer noch das unterstreichende Bindungskonzept, das Teil des MVVM-Musters ist .

Das habe ich in der direkten Kommunikation und auch in Fragen immer wieder gefragt, vielleicht ist es für alle Beteiligten eine gute Idee, sich über verschiedene Muster wie MVVM und MVU zu informieren.

Davon abgesehen gibt es sogar eine Möglichkeit, MVU auf MVVM zu implementieren, aber es bleibt die Frage, welches Problem damit gelöst werden könnte.

Haben Sie schon einmal gehört, dass jemand C# MVC oder C# MVVM sagt?

Ja, ich verstehe, dass es seltsam ist, C# oder XAML gefolgt von einem Architekturmuster wie MVVM oder MVU zu sagen. In der breiteren Entwicklergemeinde, mit der ich spreche, muss klargestellt werden, dass Sie innerhalb Ihres Projekts eine beliebige Anzahl von Kombinationen verwenden können. Damit soll nicht gesagt werden, dass sich eine „C# MVVM“ architektonisch von „XAML MVVM“ unterscheidet, sondern dass die Kombination möglich ist und die Entwicklererfahrung somit insgesamt etwas anders ist.

Ich dachte, dieser Thread könnte diskutieren, wie MVU in .NET MAUI aussehen würde, aber vielleicht ist die produktivere Diskussion hier, wie wir über mehrere Entwicklererfahrungen und Architekturmuster in einem einzigen Produkt sprechen?

Es scheint, dass dies die Richtung der meisten Kommentare hier ist, die diskutieren wollen, was wir Dinge nennen und benennen und wie wir Begriffe verwenden. Ich würde mich sehr über Ihren Beitrag dazu freuen, da ich einen Großteil der Kommunikation übernehme und sicherstellen möchte, dass ich tatsächlich Klarheit bringe und keine Verwirrung stifte.

Es geht um das Beispiel im Ankündigungsblog, das in der Community bereits so viel Verwirrung gestiftet hat.

Das war mein Beitrag zum Blog und ich entschuldige mich für die Verwirrung, die er bei Ihnen verursacht hat. Ich habe mich verschätzt, indem wir Links zum Blog von Elm und @aspnetde hinzugefügt haben , in denen wir sagten "das ist MVU" wie es hier aussehen soll/sollte.

Grundsätzlich muss ich davon ausgehen, dass sich die Autoren noch nicht wirklich mit MVU beschäftigt haben.

Wir haben zu diesem Thema ausgiebig diskutiert und debattiert. Bitte gehen Sie nicht davon aus, und ich werde versuchen, es auch nicht zu tun.

die Frage bleibt, welches Problem es lösen würde.

@dersia Das allgemeine zu lösende Problem besteht darin, den Entwicklern die Wahl zu lassen. Wenn Sie fragen, was MVU zusätzlich zu MVVM löst, habe ich keine Ahnung - dies wird nicht verlangt oder wir versuchen es zu tun.

Beim Refactoring, wie in #28 und #66 vorgeschlagen, geht es teilweise darum, die Datenbindung und MVVM-spezifischen Dinge von den Renderer-Implementierungen zu trennen, so dass Sie, wenn Sie sich für MVU entscheiden, keine zusätzlichen Funktionen übernehmen, die in MVVM verwendet werden.

Ich hätte nicht gedacht, wie viel Gewicht der Code-Schnipsel tragen würde

Aber das ist das Fleisch, oder? Und es tut mir leid, dass es nicht mit dem Etikett übereinstimmt.

@davidortinau

Es scheint, dass dies die Richtung der meisten Kommentare hier ist, die diskutieren wollen, was wir Dinge nennen und benennen und wie wir Begriffe verwenden. Ich würde mich sehr über Ihren Beitrag dazu freuen, da ich einen Großteil der Kommunikation übernehme und sicherstellen möchte, dass ich tatsächlich Klarheit bringe und keine Verwirrung stifte.

Ich bin mir nicht sicher, was ich von meiner Seite noch hinzufügen soll. Ich glaube, ich habe meine Position laut und deutlich ausgedrückt :-). Wenn Sie MVU implementieren, werden Sie an eine offene Tür stoßen. Wenn Sie sich das Snippet im Ankündigungspost und das Comet-Repository ansehen können, können Sie dies gerne tun – aber _bitte_ hören Sie auf, es MVU zu nennen.

Danke.

Wie Don in diesem Thread erwähnt wurde :-) - CC: @dsyme

Ich verstehe nicht, warum das MVU heißt, wenn es nicht so ist. Es könnte ein großartiges Paradigma sein und hier einfach großartig funktionieren - warum nicht einen passenden Begriff finden, der zum Paradigma passt und nicht verwirrt?

@aspnetde was ist von deiner Seite übrig geblieben? Ich nehme an, viel :).
Ich habe einige Teile Ihrer Diplomarbeit gelesen. Ich muss sagen, dass es mir gefallen hat. Ich habe auch das Buch von Don Syme über F# gelesen. Ich mag funktionale Programmierung. Aus meiner Erfahrung ist es prägnant, aber schwer zu fassen (verstehen). Lesbarkeit ist ein sehr wichtiger Teil des Entwicklungslebenszyklus. Tatsächlich wird viel Zeit damit verbracht, Code zu lesen. Und Rekursion ist nur schreiben. Sie können es einmal schreiben, aber fast niemand kann es lesen (ähnlich wie bei regexp).
In der Vergangenheit habe ich Redux mit Angular während meiner Prototyping-/Forschungszeit im Unternehmen ausprobiert. Ist es ein halb-elmischer Ansatz? Es war eine wertvolle Erfahrung. Ich habe gelernt, dass ich aufpassen muss, dass der Zustand nicht mutiert, und ich mir dadurch nicht den ganzen Stack merken muss, wo genau sich der Zustand plötzlich ändern kann.
Ich verstehe die Vorteile der Unveränderlichkeit, aber ich sah eine Präsentation mit Erik Meijer, der plötzlich einen Teddybärenkopf zerriss, um uns zu zeigen, dass die reale Welt wandelbar ist.

Worauf ich hinweisen möchte: Ist unser natürliches Denken nicht gegen diese Paradigmen? Was ist Ihre Erfahrung?

Ich habe viel Erfahrung mit XAML/C#/MVVM, daher frage ich mich, warum Don Syme XAML für unnötig hält.
Aus meiner Erfahrung hilft es, Belange (UI, Präsentation, Geschäftslogik usw.) zu trennen. Ich bin mir nicht wirklich sicher, ob diese DSLs (C#-Markups) und MVU dazu beitragen, die Codequalität langfristig zu verbessern. Nicht erfahrene/nicht fürsorgliche Entwickler werden die Verantwortlichkeiten vermischen. Ich brauche auch mehr Erfahrung mit MVU-Mustern, um es richtig zu verstehen, aber Sie haben beide Paradigmen ausprobiert und es ist für die gesamte Community sehr wertvoll.
Bitte teilen Sie so viel wie möglich. Danke @aspnetde!

Vielen Dank für Ihr Verständnis

@davidortinau vielleicht gab es hier ein Missverständnis, ich habe die Wahl und überlasse es jedem selbst, welches Muster / Paradigma zu verwenden. Ich wollte nur sagen, dass wir die Dinge richtig benennen sollten. Wie jeder in der Softwareentwicklung weiß, ist die Benennung von Dingen eine der schwierigsten Aufgaben, aber wenn bereits gut definierte Dinge benannt sind, sollten wir diese Namen nicht für Dinge wiederverwenden, die sie nicht sind.

Fräulein Kommunikation Miscommunication ist eines der größten Probleme in unserer heutigen Welt, ich glaube , als Gemeinschaft, als Mitwirkende an einem Projekt, als ein führendes Projekt sollten wir alle in Verständnis Dinge helfen und auch Kritik offen sein sollte und zugeben , Fehler und bekommen zusammen um das zu beheben.
In diesem Fall denke ich, dass die Verwendung falscher Formulierungen korrigiert werden muss, und damit dies geschieht, würde ich dieses Projekt gerne tun
a) verstehen, dass MVU der falsche Name für das ist, worüber wir hier sprechen
und b) den richtigen Begriff zu finden, um zu beschreiben, was wir hier zu etablieren versuchen
und dann c) alle aktualisieren und diesen neuen Namen verwenden

Ich denke, wir sind immer noch an einem Punkt, an dem wir noch zurückgehen und das Problem beheben können. Machen wir es richtig, das Schlimmste, was passieren kann, ist, dass die XF/Maui-Community MVU als etwas anderes versteht als der Rest der Welt.

Abgesehen davon bin ich ein großer Fan von MVU und ich liebe auch MVVM, und ich finde den fließenden MVVM-Ansatz (ich habe noch keinen besseren Namen) wie in Comet und das bisher präsentierte ist großartig und hilft einem viele Entwickler und ich werde es unterstützen, ich denke nur, wir sollten die Namensgebung korrigieren.

Edit: Miss Communication ist aus dem Wettbewerb ausgestiegen.

Ich verstehe die Vorteile der Unveränderlichkeit, aber ich habe eine Präsentation mit Erik Meijer gesehen, der plötzlich einen Teddybärenkopf zerreißt, um uns zu zeigen, dass die reale Welt wandelbar ist.

@tomasfabian das ist falsch.

Man muss anfangen, die Welt als eine Reihe von Ereignissen zu sehen, das ist es tatsächlich (nein, ich möchte hier keine Event-Sourcing-Diskussion starten).
Was mit dem Teddybären passiert ist, ist nur, dass seinem Zustand ein neues Ereignis hinzugefügt wurde, das Ereignis in diesem Fall ist "vom Kopf gerissen". Und da Sie feststellen können, dass ein Ereignis passiert ist, können Sie es nicht mehr rückgängig machen, da Sie nicht einfach rückgängig machen oder löschen können, was passiert. Um den Kopf wieder auf den Teddy zu bringen, benötigen Sie ein neues Ereignis namens "Kopf wieder auf den Körper genäht". 😉.

Die Diskussion über die Vorteile von FP und MVU ist hier IMHO off-topic. Bei diesem Problem ging es, dachte ich, nur um das Potenzial für Missverständnisse und genaue Namensgebung.

@isaacabraham vielleicht hast du recht und ich entschuldige mich dafür. Es ist meine Schuld. Ich weiß, dass es wichtig ist, Dinge zu benennen, aber andererseits lautet der Titel der Ausgabe "MVU ist möglicherweise nicht das, was Sie denken". Es ist also hoffentlich ein etwas umfassenderes Thema als das Benennen von Dingen.
Danke, Tomas

@tomasfabian Ich würde mich super freuen, mit dir über die Vor- und Nachteile von MVU, FP oder was auch immer, real oder imaginär zu plaudern 😊 Denke nur nicht, dass dies das geeignete Forum dafür ist.

@davidortinau
Insoweit, welche Sprachfeatures und Architekturänderungen hilfreich wären, kann ich hoffentlich mit einigen Vorschlägen beitragen:

* Das Schlüsselwort new und andere syntaktische Geräusche.
Im Gegensatz zu Dart oder Kotlin bleibt C# wahrscheinlich für immer an einem erforderlichen new Schlüsselwort hängen, da es eine bahnbrechende Änderung und ein unpopulärer Vorschlag ist, es optional zu machen, selbst als Opt-in-Anweisung pro Datei. Anstelle dessen, vielleicht eine offizielle (und gepflegte) statische Klasse (oder eine statische Klasse pro MAUI-View-Namespace), die statische Methoden enthält, die nur Konstruktoren umhüllen und alle init-only-Eigenschaften initialisieren, wenn überhaupt, zumindest für den Kernsatz von MAUI-Ansichtsobjekte. Dann können wir eine using static Direktive an den Anfang unserer .cs-Dateien mit Ansichtscode setzen und dann die Methoden ohne das syntaktische Rauschen von new aufrufen. Dies würde die Unordnung und das Rauschen der C#-Ansichtsfunktionen etwas reduzieren. Natürlich könnten diese statischen Methodenkonstruktor-Wrapper automatisch von der Community generiert werden (ich habe etwas Ähnliches für Xamarin.Forms gemacht, um es mit CSharpForMarkup zu verwenden), aber es wäre schön, wenn ein Satz von ihnen in der Box gepflegt würde von das MAUI-Projekt.

Darüber hinaus würden alle C#-Sprachvorschläge, die dazu beitragen würden, syntaktisches Durcheinander oder Rauschen in großen Ausdrucksbäumen zu reduzieren (wie es bei MVU/Comet/CSharpForMarkup-Ansichtsfunktionen üblich ist), sehr hilfreich sein. C#9 hat in dieser Hinsicht einen LANGEN Weg zurückgelegt, um die M- und U-Teile von MVU zu verbessern, aber der V-Teil ist in Bezug auf die Syntax immer noch ein Problem.

* Erweiterungseigenschaften *
Ich weiß, dass der Vorschlag "extension-everything" vorerst auf Eis gelegt ist, aber eine Sache, die für MVVM-mit-C#-Markup (z. B. CSharpForMarkup mit Xamarin.Forms) hilfreich sein könnte, wären Erweiterungseigenschaften. Bei CSharpForMarkup musste jeder Helfer mit einer Erweiterungsmethode implementiert werden, aber in einigen Fällen würde eine Erweiterungseigenschaft (die im Objektinitialisierer verwendet werden kann) viel besser aussehen:

// Instead of this:
public View Body() =>
    new Widget() {
        BuiltInProperty = "initial value",
    }.SetExtensionProperty("initial value");

// the extension property could be included in the object initializer:
public View Body() ->
    new Widget() {
        BuiltInProperty = "initial value",
        ExtensionProperty = "initial value",
    };

Dies gilt wirklich nur für veränderliche Ansichtsobjektbäume, wie in MVVM mit C# für Markup. Für MVU oder andere funktionale UI-Architekturen gilt dies nicht, da die Ansichtsobjekte unveränderlich sind. In diesen Fällen ist eine fließende Verlängerungsmethode noch besser geeignet.

* Seien Sie weniger eigensinnig (oder auf niedrigem Niveau, wenn Sie es vorziehen) in Bezug auf die Staatsverwaltung *
Ich denke, eine der größten Hindernisse für den Einstieg in die Implementierung von MVU auf Xamarin.Forms war das Fehlen von zwei wesentlichen Komponenten: dem leichtgewichtigen Objektgraphen, den die Ansichtsfunktionen zurückgeben könnten, den das Framework in tatsächliche Komponenten "rendern" könnte (mit ihren plattformspezifische Darstellungen, etc...). Und der zweite Teil ist eine Diffing-Engine, die die schweren plattformspezifischen Ansichten effizient aktualisiert, indem sie nach Unterschieden zwischen einem Rückgabewert einer Ansichtsfunktion und einem anderen sucht, einschließlich einer Möglichkeit, Diffs effizient durchzuführen, indem partielle Diffs usw.

Es hört sich so an, als würde MAUI jetzt diese beiden wesentlichen Teile liefern, was großartig ist! Es scheint jedoch zumindest oberflächlich sehr eng mit einer eigenwilligen Art der Zustandsverwaltung verbunden zu sein, von der einige in der MVU-Community sagen würden, dass sie MVVM näher steht als MVU oder ähnliche "funktionale" UI-Architekturen. Ich denke, meine Vorliebe wäre es, die beiden oben genannten wesentlichen Teile (leichtes Ansichtsobjektdiagramm und effiziente Diffing-Engine) beizubehalten und sie mit einem Komponentensystem auf niedrigerer Ebene zu verbinden, auf das MVU oder Comet gemäß den Entwicklern effizient geschichtet werden könnten Auswahl. Vielleicht ist das schon das Ziel, und ich sehe es nicht? Wenn ja, würde ich gerne mehr darüber diskutieren, zumindest mit einigen grundlegenden Beispielen.

@aspnetde warum hast du deinen Beitrag gelöscht?

@tomasfabian

Aus meiner Erfahrung hilft es [MVVM], Anliegen zu trennen (UI, Präsentation, Geschäftslogik usw.)

Ja tut es. Ich habe einige gute Erfahrungen mit großen Xamarin.iOS- und Xamarin.Android-Anwendungen gemacht, die mit MvvmCross erstellt wurden. Obwohl ich Bibliotheken heute Frameworks vorziehe, denke ich, dass all diese Projekte (einige mit sechsstelligen LOCs) sowohl technisch als auch aus geschäftlicher Sicht ein Erfolg waren.

Ich denke, dass MVVM besonders gute Arbeit leistet, wenn es um die Skalierung einer Anwendung geht. Insbesondere im mobilen Bereich, wo wir gezwungen sind, Monolithen auszuliefern, hat es uns geholfen, unsere Apps in unabhängige Module umzugestalten, nachdem sie eine bestimmte Größe überschritten haben.

Ist unser natürliches Denken nicht gegen diese Paradigmen ([MVU])? Was ist Ihre Erfahrung?

Ich glaube nicht. Nutzen Sie Ihre Erfahrung mit Redux für die Speicherung und stellen Sie sich vor, dass Ihre gesamte Anwendung von seinen Vorteilen profitiert. Obwohl es auf den ersten Blick komplexer erscheint, ist es meiner Erfahrung nach viel einfacher zu verstehen und zu bearbeiten. Wie @forki oft

Ich bin mir nicht wirklich sicher, ob diese DSLs (C#-Markups) und MVU dazu beitragen, die Codequalität langfristig zu verbessern.

Während sowohl MVU als auch MVVM unterschiedliche Vorteile haben, haben beide auch unterschiedliche Nachteile.

Obwohl wir unsere MVVM-Projekte für erfolgreich hielten, verloren mein Team und ich einige Haare beim Debuggen. Insbesondere in einem Projekt begannen wir unter Komplexität zu leiden, die durch mangelnde Erfahrung neuer Teammitglieder und Missverständnisse verursacht wurde – wie Sie bereits erwähnt haben. Ich denke, das ist bei MVU bei strenger Anwendung weniger wahrscheinlich, weil es die Grenzen der Funktionsweise so eng definiert, dass es fast schwieriger ist, daraus auszubrechen und Dinge falsch zu bauen, als umgekehrt.

Für MVU sehe ich zwei große Probleme. Erstens: Skalierung. Viele plädieren für ein einziges Programm. Ich bin hier skeptisch (und denke, mehrere Programme/Module wären der bessere Weg). Zweitens: Im Moment sitzt ein Ding wie Fabulous auf Xamarin.Forms. Es ist also eine Abstraktionsschicht über einer Abstraktionsschicht über einer Abstraktionsschicht über iOS/Android. Das ist eine enorme Komplexität. Sie beschäftigen sich also nicht nur mit ungelösten Fehlern, die niemanden interessieren, sondern es ist auch eine mehr oder weniger mühsame und unangenehme Aufgabe, eine Abstraktionsschicht (Fabulous) zu aktualisieren, wenn sich die andere (Xamarin.Forms) ändert.

Da würde ich eine große Chance für MAUI sehen. Ich würde ehrlich gesagt gerne sehen, dass sich die Fabulous-Maintainer hier mit Microsoft zusammenschließen. Und ich hoffe wirklich, dass Microsoft es nicht ruiniert, wie es andere Teile der Organisation in der Vergangenheit getan haben.

Thomas

Als ich neulich die offizielle Ankündigung las, war ich überrascht, was dort als MVU präsentiert wurde:

readonly State<int> count = 0;

[Body]
View body() => new StackLayout
{
    new Label("Welcome to .NET MAUI!"),
    new Button(
        () => $"You clicked {count} times.",
        () => count.Value ++)
    )
};

Soweit es mich betrifft, ist dies nicht MVU . Ich schrieb schon unten einige Gedanken darüber , warum ich denke , so hier .

Don Syme, der, wie ich verstanden habe, mehrere Monate im Jahr 2018 damit verbracht hat, MVU auf Xamarin.Forms zu implementieren und zu bauen, was später Fabulous wurde , ist etwas diplomatischer , aber das Endergebnis ist dasselbe.

Also, was ist mein Punkt?

• Ich würde mich freuen, wenn Sie das reale Architekturmuster implementieren, egal ob in C# oder F#. Die Kontaktaufnahme zu den Leuten hinter Fabulous könnte hier ein Anfang sein.
• Wenn Sie daran nicht interessiert sind, aber eine klare Vision haben, auf dem aufzubauen, was heute als Comet-Bibliothek verfügbar ist, ziehen Sie bitte in Betracht, einen passenderen Namen für dieses "App-Modell" zu verwenden. Erfinden Sie etwas Neues. Nennen Sie es MSMVU. Was auch immer. Aber verkaufen Sie keine Äpfel für Orangen.

Beifall!

Warum sollten sie es MSMVU nennen? Komet war MVU und wird es auch bleiben. Und Maui ist eine MVU.

Ich denke, es ist zu früh, um zu sagen, ob .NET MAUI MVU ist oder nicht

Es geht nicht darum, ob MAUI am Ende MVU wird. Es geht um das Beispiel im Ankündigungsblog, das in der Community bereits so viel Verwirrung gestiftet hat. Grundsätzlich muss ich davon ausgehen, dass sich die Autoren noch nicht wirklich mit MVU beschäftigt haben. Wenn man über "C# MVU" spricht, wird dies nicht besser.

Es verursacht keinerlei Verwirrung. Ist nur, dass einige Leute nicht damit umgehen können, wenn C# MVU macht.

SwiftUI (von dem Comet den größten Teil seiner Inspiration bezieht) neigt dazu, sein Muster MVVM zu nennen, obwohl es keine expliziten Richtlinien gibt.
Ich habe jedoch keine Erwähnung von MVU gefunden.

@TimLariviere https://github.com/Clancey/Comet#key -concepts
Im Grunde nannte Comet es MVU und vermisste bereits den Punkt der Nachrichtenschleife, die wir in älteren Definitionen von MVU haben

SwiftUI (von dem Comet den größten Teil seiner Inspiration bezieht) neigt dazu, sein Muster MVVM zu nennen, obwohl es keine expliziten Richtlinien gibt.

Es ist nicht einmal falsch, sich das Beispiel am Anfang dieses Beitrags hier anzuschauen :

Ich habe jedoch keine Erwähnung von MVU gefunden.

Im selben Beitrag wird auch kurz darauf eingegangen (als Kombination aus SwiftUI + Redux = TEA). Obwohl es dann eine seltsame Wendung zu "Clean Architecture" nimmt 😄

Da ich hier erwähnt wurde, möchte ich nur ein paar Dinge sagen.

• Ich finde MAUI großartig und ich denke, es kann nützlich sein, etwas über MVU als Architektur zu lernen, damit die Leute MAUI verstehen.

• Es ist leicht, sich bei Wörtern aufzuhängen, und wir sollten wahrscheinlich alle eine Verschnaufpause einlegen und versuchen, uns zu diesem Zeitpunkt keine Sorgen zu machen, da es viel Zeit gibt, die verwendeten Wörter anzupassen, und ich denke, die Botschaft über die genaue Terminologie war habe gehört. Persönlich denke ich, dass Elm festgestellt hat, dass die schmucklose, unqualifizierte Verwendung von "MVU" explizite Nachrichten, explizite Aktualisierung, funktionale Modelle, Neuberechnung der funktionalen Ansicht und differenzielle Aktualisierung bedeutet. Aber es gibt viele Variationen von MVU und MAUI ist ein Punkt in diesem Spektrum (das bis hin zu MVVM als eine Art manuell inkrementalisiertes Nachrichtenverarbeitungssystem mit implizitem, durchdringenden veränderlichen Zustand reicht). Aus dieser Perspektive ist die SwiftUI-Kommunikation interessant.

• Ich stelle fest, dass die Leute dazu neigen, sehr starke Überzeugungen und Meinungen in diesem Bereich zu haben und die Dinge sehr persönlich nehmen können. Ich weiß, wie das ist, und wie beim Programmiersprachendesign denke ich, dass alle Punkte in diesem Bereich Vor- und Nachteile haben. Ich möchte alle ermutigen, auszuprobieren, zu verwenden, zu lernen, zu teilen und zusammenzuarbeiten, um das bestmögliche Spektrum an Technologien zu entwickeln.

@dyme
Ich denke, der richtige Begriff für die Comet/MAUI-Architektur ist eine Variation des unidirektionalen Datenflusses (oder UDF), aber nicht MVU, da MVU selbst eine sehr spezifische Variation von UDF ist. MAUI/Comet qualifiziert sich sicherlich als UDF-Framework (wie SwiftUI), aber nicht als MVU-Framework. Es gibt mehrere Variationen von UDF, einschließlich MVU, Flux, Redux, React usw., aber es ist eine Fehlkommunikation, Comet MVU zu nennen, wenn es überhaupt nicht MVU ist.

Im Gegensatz zu MVU ist das Modell veränderbar und wird durch Code in der Ansichtsfunktion mutiert. Mutationen werden dann beobachtet und Ansichten reagieren auf diese Mutationen durch erneutes Rendern. Es ist immer noch unidirektional, da Ansichten nicht mutiert sind, aber es gibt keine Aktualisierungsfunktion, keine Nachrichten und kein Nachrichtenversand - also keine MVU. Es ist näher an einer unidirektionalen Variation von MVVM.

@JeroMiya Danke, haben Sie eine Referenz für diese Terminologie?

@dsyme Ich habe keine spezifische Referenz dafür, aber ich hörte zum ersten Mal, dass der Begriff in den frühen Tagen von React verwendet wurde, insbesondere in Bezug auf React selbst und einige der frühen Muster, die wie Redux und Flux auftauchten. Ich erinnere mich an einen Artikel, der eine Reihe von UDF-Varianten beschrieb (hauptsächlich im React-Bereich), aber ich kann ihn jetzt nicht finden.

Davon abgesehen ist es keine formale Architektur - eher das Grundkonzept, dass die Ansicht eine Funktion des Modells ist, im Gegensatz dazu, dass die Ansicht ein zustandsbehafteter Objektbaum ist, der als Reaktion auf Ereignisse mutiert. Das UDF-Konzept gibt nicht unbedingt an, wie das Modell aktualisiert wird oder ob es veränderlich oder unveränderlich ist. MVU erweitert das UDF-Konzept nicht nur auf die Ansicht selbst, sondern auch auf den Prozess der Aktualisierung des Modells. In MVU ist das Modell also auch unveränderlich, und UI-Zustandsänderungen werden als Befehle dargestellt, die neue Modelle erzeugen, die neue Ansichten auslösen.

Es ist natürlich kein neues Konzept - schon vor React gelten die meisten serverseitigen Web-Frameworks wie Asp.Net MVC, Rails, sogar PHP technisch als unidirektional. Es war einfach nicht üblich für Mainstream-SPA-Frameworks und clientseitige UI-Frameworks, bevor React auf den Markt kam.

@dsyme Ich habe keine spezifische Referenz dafür, aber ich hörte zum ersten Mal, dass der Begriff in den frühen Tagen von React verwendet wurde, insbesondere in Bezug auf React selbst und einige der frühen Muster, die wie Redux und Flux auftauchten. Ich erinnere mich an einen Artikel, der eine Reihe von UDF-Varianten beschrieb (hauptsächlich im React-Bereich), aber ich kann ihn jetzt nicht finden.

Davon abgesehen ist es keine formale Architektur - eher das Grundkonzept, dass die Ansicht eine Funktion des Modells ist, im Gegensatz dazu, dass die Ansicht ein zustandsbehafteter Objektbaum ist, der als Reaktion auf Ereignisse mutiert. Das UDF-Konzept gibt nicht unbedingt an, wie das Modell aktualisiert wird oder ob es veränderlich oder unveränderlich ist. MVU erweitert das UDF-Konzept nicht nur auf die Ansicht selbst, sondern auch auf den Prozess der Aktualisierung des Modells. In MVU ist das Modell also auch unveränderlich, und UI-Zustandsänderungen werden als Befehle dargestellt, die neue Modelle erzeugen, die neue Ansichten auslösen.

Es ist natürlich kein neues Konzept - schon vor React gelten die meisten serverseitigen Web-Frameworks wie Asp.Net MVC, Rails, sogar PHP technisch als unidirektional. Es war einfach nicht üblich für Mainstream-SPA-Frameworks und clientseitige UI-Frameworks, bevor React auf den Markt kam.

@JeroMiya danke dafür, genau so verstehe ich MVU.
Ich würde sogar sagen, dass MS Excel eine der ältesten und immer noch am häufigsten verwendeten Anwendungen ist, die MVU in ihrer besten Form verwendet und beispielhaft darstellt.

@dsyme beim Lesen Ihrer Kommentare habe ich das Gefühl, dass Sie sich auf MAUI als den Begriff für die diskutierte Architektur beziehen (CSharpForMarkup mit MVVM).
Bitte machen Sie mir klar, dass dies nicht das ist, was Sie unter MAUI verstehen oder wenn es so ist.
Nach meinem Verständnis ist MAUI nur das nächste MS Application Framework, das XF irgendwann in der Zukunft ersetzen wird.

Ich mag die Art und Weise, wie dieses Thema und seine Kommentare verlaufen. Danke für alle, die mitmachen. Vielleicht können wir gemeinsam all die verschiedenen Architekturen als mögliche Flavors für MAUI etablieren und richtig benennen.

@dersia Danke! Nur eine Anmerkung aus meiner eigenen Erfahrung mit CSharpForMarkup: Es ist ein bisschen niedriger als MVVM - eher eine Reihe von Erweiterungsmethoden und Dienstprogrammen, um C#-Markup schlanker und schöner zu machen. Sie können sicherlich ein MVVM-Muster damit implementieren, da es Helfer hat, um ViewModel-Bindungen zu vereinfachen, aber was ich letztendlich getan habe, ist, meine gesamte Ansichtslogik in Redux anstelle von ViewModels zu implementieren. Es müssen nur einige Erweiterungsmethoden hinzugefügt werden, um Ansichtseigenschaften an Zustandsselektoren zu binden, die nur Func<StateType, ChildStateType> Ich übergebe die Operatoren Select und DistinctUntilChanged im Redux-Zustandsspeicher ein Observable<StateType> . Nicht ganz unidirektionaler Datenfluss, aber ich hatte keine ausgereifte Methode, um UI-Objektbaum-Diffs und Ansichtsfunktionen wie jetzt Fabulous durchzuführen.

Vor einiger Zeit hat uns die REST-Polizei versucht, uns einzureden, dass wir alle nicht REST heißen sollten. Jeder nennt es heute noch REST und wir alle sind noch am Leben und wohlauf. 😉.

@bitbonk die REST-Community hat den Begriff aufgegeben, weil er immer nutzloser wurde, da immer mehr Dinge in die Mischung geworfen wurden. Sie verwenden jetzt "Hypermedia", um sich auf REpresentational State Transfer zu beziehen. REST bedeutet heute eigentlich nur noch „nicht SOAP“ oder „JSON over HTTP“, die beide ihren Kerngedanken nicht vermitteln können. Die Kommentatoren hier hoffen, das gleiche Schicksal für MVU zu vermeiden.

@davidortinau @tomasfabian , ich habe noch kein Beispiel für MVU auf MAUI gesehen. Ich werde heute Abend versuchen, ein Beispiel zu erarbeiten. Ich habe gerade etwas Ähnliches für WinForms hier gemacht . Ich denke, es sollte nicht zu schwer sein.

@JeroMiya Danke, haben Sie eine Referenz für diese Terminologie?

@dsyme , ich denke, es entstand mit React Flux, aber sie wiesen auf Spielarchitekturen hin, @TIHan diskutiert

• https://reactjs.org/blog/2014/05/06/flux.html
• https://www.infoq.com/news/2014/05/facebook-mvc-flux/
• https://facebook.github.io/flux/
• https://github.com/topics/unidirektional-data-flow

Hier ist mein Versuch eines C#-Beispiels. Ich habe kein MAUI zur Verfügung, um dies als echtes Beispiel zu versuchen. Es gibt keine Vorschau, oder? Jedenfalls ist dies eine grobe Übersetzung der Idee.

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

Ich habe mal kurz etwas Ähnliches probiert , bis auf den Ansichtsteil. Mit Records, die auf C# 9 kommen, wird dies noch vernünftiger.

Ich bin relativ neu bei MVU und habe wahrscheinlich im Vergleich zu vielen von Ihnen sehr wenig Erfahrung damit. Aber die MVU-Konzepte haben definitiv mein Interesse geweckt und es macht mir Spaß. Ich freue mich sehr zu sehen, dass C#-Entwicklern ein Framework zur Verfügung gestellt wird, das die Entwicklung im MVU-Muster unterstützt.

Ich stimme voll und ganz zu, dass MAUI MVU nicht die typische MVU ist und einen großen Einfluss von SwiftUI hat. Sein Hauptautor Clancey selbst hatte es in fast allen seinen Sitzungen sehr deutlich gemacht. Wir alle wissen, dass Redux stark von MVU beeinflusst wird, ebenso wie SwiftUI, Flutter und viele andere Frameworks. Keine davon sind reine MVU.

Aber ich bin sicher, wir sind uns alle einig, dass das nächste Architekturmuster für all diese Frameworks MVU ist. Das ist der Grund, warum die Leute darauf verweisen. Und denken Sie daran, dass wir über einen Blogtitel für ein Framework sprechen, das in weiteren anderthalb Jahren veröffentlicht wird.

Und wenn Sie sagen, dass die Leute sich über diesen Blogtitel ärgern. Ich denke nicht, dass wir uns wirklich Sorgen um sie machen sollten. Die Community muss noch weitermachen. Lassen Sie uns unsere Energie aufwenden, um diesen Rahmen zu verbessern. Machen Sie sich keine Sorgen um die kleinen Details.

Aber ich bin sicher, wir sind uns alle einig, dass das nächste Architekturmuster für all diese Frameworks MVU ist. Das ist der Grund, warum die Leute darauf verweisen.

Hunde, Pferde, Katzen und Schimpansen sind alle sehr nah beieinander. Von nun an werde ich sie alle als Katzen bezeichnen.

:) Nun, Sie müssen nicht. Aber lassen Sie mich Ihnen etwas sagen: Katzen, Tiger, Leoparden usw. werden als Katzen bezeichnet. Und ich freue mich, dass Sie es angesprochen haben. Denn genau das ist hier der Fall.

@aspnetde : Thomas, mit allem, was gesagt wurde. Ich muss sagen, dass Ihr ursprünglicher MVU-Blog einer der besten Artikel ist, der das Konzept sehr klar und präzise erklärt. Ich habe einiges dazu gelernt. Danke schön

@libin85 da liegt genau das Problem. Sie begannen, Dinge aufzuzählen, die tatsächlich in eine Kategorie fallen, und ignorierten die, die es nicht sind. Wenn Sie das MAUI-Sample in die MVU-Kategorie einordnen, ordnen Sie im Grunde einen Schimpansen in die Kategorie Katzen ein.

Dies sind Ähnlichkeiten mit MVU-Implementierungen, wie beispielsweise eine unveränderliche Ansicht. Aber es gibt deutliche Unterschiede wie, es gibt keine Nachrichtenschleife und keine explizite Update-Funktion. Das Modell wird direkt in der Ansicht mutiert. Dies war etwas, was die Leute ausdrücklich nicht wollten, als sie MVU entwickelten. In manchen Sprachen wäre das sogar unmöglich – deshalb ist die MVU entstanden. Und warum es populär wurde. Jetzt sollten wir vorsichtig sein, wenn wir diese Eigenschaften aus unserer Definition von MVU entfernen.

@forki : Ich bin nicht gegen alles, was du gesagt hast. Tatsächlich sind es die Punkte, die Sie im letzten Kommentar angesprochen haben, die wir als Community diskutieren müssen und nicht die Titel in einem Blog-Post. Das ist mein Punkt. Das ist positiv zu diskutieren und der Rahmen wird davon profitieren.

Ich stimme zu, dass der Name ein kleines Detail ist, das nicht von wichtigeren Aspekten ablenken soll. Der Grund, warum ich es erwähnt habe, ist jedoch, dass ich MAUI persönlich nicht als Gemeinschaftsleistung sehe, bei der der gesunde Menschenverstand schließlich zu einer gemeinsam vereinbarten Lösung führt. Es ist ein Microsoft-Produkt, bei dem die endgültigen Entscheidungen hinter verschlossenen Türen getroffen werden. Ich bin hier in meiner Funktion als Kunde, um meine Bedenken zu äußern.

Aber ich bin sicher, wir sind uns alle einig, dass das nächste Architekturmuster für all diese Frameworks MVU ist.

@libin85 Ich stimme nicht zu, dass dies das nächste architektonische Muster ist. MVU ist eine Reihe von Einschränkungen gegenüber dem, was im Allgemeinen wie MVP oder Model View Presenter aussieht. MVVM ist ähnlich und geht in eine andere Richtung, da der Presenter ein ViewModel mit Datenbindungen ist. MVP selbst ist eine eingeschränkte Form von MVC. Ich denke, es ist ziemlich sicher zu sagen, dass dies alles Nachkommen von MVC und sogar MVP sind, aber zu sagen, dass MVU für SwiftUI, Flux usw. gilt, macht MVU zu einem bedeutungslosen Begriff.

Ich stimme zu, dass der Name ein kleines Detail ist, das nicht von wichtigeren Aspekten ablenken soll.

Nein, Namen sind wichtig. Sie sind schwer zu begründen und ihre Bedeutung zu bewahren. Siehe auch REST, das ich oben besprochen habe. REST wird so missbraucht, dass es außer im Marketing-Jargon keine Bedeutung mehr hat. Ich möchte nicht, dass dies mit MVU passiert, insbesondere wenn es Bedingungen für das gibt, was MAUIs "MVU" bietet.

Für das, was es wert ist, denke ich, dass die MAUI "MVU" eine schöne Alternative zur MVVM-Option ist. Genau wie bei REST müssen Sie nicht die Definitionssache machen, um etwas Nützliches und Gutes zu machen. Nur bitte den Namen nicht mit Alternativen verschmutzen, die deutlich von einem wohldefinierten und etablierten Muster abweichen. Schließlich wäre MVU _auch_ eine schöne Alternative zu den MVVM- und Comet-Optionen.

Für das, was es wert ist, denke ich, dass die MAUI "MVU" eine schöne Alternative zur MVVM-Option ist. Genau wie bei REST müssen Sie nicht die Definitionssache machen, um etwas Nützliches und Gutes zu machen, aber bitte den Namen nicht mit Alternativen verschmutzen, die deutlich von seiner Definition abweichen.

VOLLE ACK.

Warum sollten sie es MSMVU nennen? Komet war MVU und wird es auch bleiben. Und Maui ist eine MVU.

@saint4eva Sie werden als MVU "vermarktet", aber per Definition nicht.

Ich stimme zu, dass der Name ein kleines Detail ist, das nicht von wichtigeren Aspekten ablenken soll.

Nein, Namen sind wichtig. Sie sind schwer zu begründen und ihre Bedeutung zu bewahren. Siehe auch REST, das ich oben besprochen habe. REST wird so missbraucht, dass es außer im Marketing-Jargon keine Bedeutung mehr hat. Ich möchte nicht, dass dies mit MVU passiert, insbesondere wenn es Bedingungen für das gibt, was MAUIs "MVU" bietet.

Für das, was es wert ist, denke ich, dass die MAUI "MVU" eine schöne Alternative zur MVVM-Option ist. Genau wie bei REST müssen Sie nicht die Definitionssache machen, um etwas Nützliches und Gutes zu machen. Nur bitte den Namen nicht mit Alternativen verschmutzen, die deutlich von einem wohldefinierten und etablierten Muster abweichen. Schließlich wäre MVU _auch_ eine schöne Alternative zu den MVVM- und Comet-Optionen.

Ich stimme dem meisten zu, was Sie gesagt haben, aber ich denke, "Maui MVU" ist immer noch so schlecht und verwirrend. Ich würde wahrscheinlich "Maui MVP" oder MVC nehmen. Beides funktioniert und ist näher an dem, was im Blogbeitrag präsentiert wird, als MVU.

Bearbeiten hinzufügen:
Ich bin mir nicht einmal sicher, wo die vorgeschlagene Version lebt. Ich meine die Logik in MVVM lebt im ViewModel, bei MVU lebt sie innerhalb der Update-Funktion und bei MVP lebt sie im Presenter und bei MVC lebt sie im Controller.

Wird es eine Ansicht geben, in der alles lebt? Oder lebt alles nur in einer Klasse, die nach dem Domänenmodell benannt ist und der Ansicht, Logik und dem Modell dient? Sollen Modelle separate Klassen (Typen) oder Datensätze sein?

Ich denke, das ist für mich der größte Schmerzpunkt hier, ich habe keine Ahnung, wie es "dargestellt" wird und kann daher keine Update-, Modell- und Ansichtsfunktion sehen.

Out of the box scheint mir, dass MAUI etwas niedriger ist als die bisher besprochenen Muster - wirklich nur das Modell (oder der Zustand) und der Ansichtsteil dieser anderen Muster. Etwas, auf das Sie vielleicht aufbauen könnten, um diese anderen Muster zu implementieren (obwohl das Zustandsmanagement etwas eigensinnig ist).

Wenn beispielsweise T in State<T> eine ViewModel-ähnliche Klasse ist und Sie einen separaten Satz von Datenmodellklassen hinzufügen, erhalten Sie am Ende so etwas wie MVVM mit eine unidirektionale Ansicht.

Auf der anderen Seite, wenn Sie ein Redux-ähnliches Zustandsverwaltungssystem hinzufügen und das Redux-Zustandsmodell als Ihr T in State<T> , dann ist das, was Sie am Ende haben, etwas, das der MVU sehr nahe kommt , wenn auch nicht ganz so vollständig integriert wie eine traditionelle MVU wie Elm/Fabulous. Vielleicht könnten Sie MAUI-Ansichten hinter dem MVU-Framework verstecken, wie es Fabulous mit Xamarin.Forms tut?

Ich bin mir nicht sicher, wie Sie ein MVC- oder MVP-Muster über MAUI implementieren würden. Als groben ersten Durchgang denke ich vielleicht, wenn Sie eine separate Klasse erstellen, die "Aktionen" für die Ansichtsfunktion verfügbar macht. Angenommen, Sie haben ein MAUI-Bestätigungsdialogfeld und Ihre "Controller"-Klasse hat eine "ClickOK"-Methode und eine "ClickCancel"-Methode. Die MAUI-Ansicht leitet Klickereignisse von der Ansicht an den Controller weiter, der entweder ein neues Modell generiert oder das vorhandene Modell mutiert.

@JeroMiya Ich stimme zu, definitiv kann die Verwendung des Redux-Musters es näher an MVU bringen und die Architektur viel weniger opiniert halten. Ich bin ein glücklicher Benutzer von React-Redux, React-Hooks, ReactiveX und neuerdings auch von Blazor Apps :heart: Fluxor :heart: . @mrpmorris kann dieses Gespräch beitragen.

Hier ist mein Versuch eines C#-Beispiels. Ich habe kein MAUI zur Verfügung, um dies als echtes Beispiel zu versuchen. Es gibt keine Vorschau, oder? Jedenfalls ist dies eine grobe Übersetzung der Idee.

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

Würde dies für Updates höhere Leistungskosten verursachen als im Microsoft-Beispiel? In diesem Modell würde, wenn ich das verstanden habe, eine neue Ansicht instanziiert, die alle UI-Elemente enthält, im Gegensatz zum MS-Beispiel, wobei die vorhandenen Ansichtselemente an Ort und Stelle bleiben und lediglich der Wert des Labels aktualisiert wird (ein anfallender, was auch immer re -Sizing-Kosten, die dies haben könnte).

Dieser Unterschied scheint einer der Kernunterschiede zu sein, der diese Diskussion um die Benennung antreibt, und daher bin ich gespannt, ob es in der traditionell definierten MVU-Architektur andere Techniken zur effizienten Aktualisierung der Benutzeroberfläche gibt, und wenn ja, werden sie auf der Ebene der Rendering-Engine?

@markmccaigue in Bezug auf die Leistung: Oft werden MVU-Systeme mit einer virtuellen Ansicht (oder virtuellen DOM im Fall von HTML) und einer Diffing-Engine geliefert. Nach der Differenzierung von DOM mit virtuellem DOM muss das Framework also nur noch einen Patch auf das DOM anwenden. Dies ist in der Regel sehr effizient, insbesondere wenn Sie mit unveränderlichen Datenstrukturen arbeiten.

Hallo!!

Ich werde dieses Thema vorerst schließen.. Ich würde dies gerne zu einer Diskussion machen, aber github möchte das nicht zum Laufen bringen :-/

Wenn jemand diese Unterhaltung fortsetzen möchte, erstellen Sie bitte ein Diskussionselement und verweisen Sie dann auf dieses Problem