Maui: MVU might not be what you think it is

Thanks @aspnetde, I hope you'll join us as we work on implementing this idea over the next 18 months or so. Given your history with MVU, I expect you'll have much to contribute.

I think it's too early to say that .NET MAUI is or is not MVU since we haven't actually built it yet. :)

Yes, we have a prototype. Yes, it's inspired by the Comet experiment. And yes, we know that there is concern that what we have shown thus far doesn't match everyone's definition of MVU.

My hope is that we can collaborate! If what we end up designing and shipping deserves a different label, I agree we should give it one.

How would you expect to see C# MVU in .NET MAUI?

What new language features would you see needed, if any?

Could/should we consider integrating Fabulous and/or what patterns does it make sense to make common between C# and F#, and what ought to be different?

How would you expect to see C# MVU in .NET MAUI?

Have you ever heard anyone saying C# MVC or C# MVVM? _Model-View-Update_ aka _The Elm Architecture_ is a well-defined architectural pattern, not a language-dependent implementation.

What new language features would you see needed, if any?

• While union types would help to simplify the definition of messages massively, that can be done through interfaces/abstract classes and a sub-class per message, although that requires a bit more boilerplate code to write.
• In order to process messages, pattern matching is helpful if not required. I think the current state of C# switch expressions is already good enough for that, as the shape of messages will be simple.
• Last but not least, the most important feature I see is immutability by default and enabled structural equality comparisons. As far as I remember the current proposal of records in C# 9 (aka data classes), those will deliver exactly that.

So C# 9 would, while still be more noisy than F#, be good to go from my current point of view.

Could/should we consider integrating Fabulous and/or what patterns does it make sense to make common between C# and F#, and what ought to be different?

As written above, there should not be anything particularily language-specific in the overall approach as MVU itself is just the architectural style or app model as you call it.

@TimLariviere Has made some proposals to move Fabulous forward recently, which also includes ideas around a more SwiftUI-like DSL. You might want to have a look and/or engange there, too.

By the way: I've made a 1:1 comparison of XF + C# + MVVM and XF + F# + MVU last year, the results can be found here – including source code.

I think it's too early to say that .NET MAUI is or is not MVU

It's not about if MAUI will be MVU in the end. It's about the sample in the announcement blog that already raised so much confusion in the community. Basically I have to assume that the authors did not really look into MVU yet. Talking about "C# MVU" doesn't make this any better.

I agree with @aspnetde and @forki the problem here lies in communication.

I think none of us is arguing to drop or change the comet inspired C# DSL for MAUI/XF, but even if we take what is so far being done with it, this is still using the underlining binding-concept which is part of MVVM pattern.

This is something I have been asking over and over again in direct communication and alo in issues, maybe it is a good think for everyone involved to read up on different patterns like MVVM and MVU.

That being said, there is even a way of implemting MVU on top of MVVM, but the question remain what problem it would solve.

Have you ever heard anyone saying C# MVC or C# MVVM?

Yes, I understand it's odd to say C# or XAML followed by an architectural pattern like MVVM or MVU. Among the broader community of developers I speak with, there is the need to make clear that you can utilize any number of combinations within your project. The intention is not to say that a "C# MVVM" is architecturally different than "XAML MVVM", but that the combination is possible and the developer experience as a whole is thus slightly different.

I thought this thread might discuss how MVU would look in .NET MAUI, but perhaps the more productive discussion here is how we talk about multiple developer experiences and architecture patterns within a single product?

It seems like that's the direction of most comments here, wanting to discuss what we call and label things and how we use terms. I would dearly love your input on this, since I do much of the communication and want to make sure I'm indeed adding clarity and not generating confusion.

It's about the sample in the announcement blog that already raised so much confusion in the community.

That was my contribution to the blog and I apologize for the confusion it created for you. I miscalculated that by adding links to Elm and @aspnetde's blog that we were saying "this is what MVU is", and I didn't anticipate how much weight the code snippet would bear for those of you with existing MVU experience and expectations as to what it would/should look like here.

Basically I have to assume that the authors did not really look into MVU yet.

We have had extensive conversation and debate on the topic. Please don't assume, and I'll try not to as well.

the question remain what problem it would solve.

@dersia the general problem to be solved is giving developers choice. If you're asking what MVU on top of MVVM solves, I have no clue - this isn't something being asked for or something we are trying to do.

The refactoring as proposed in #28 and #66 is partially about separating the databinding and MVVM specific things from the renderer implementations such that if you opt for MVU you won't be taking on additional features used in MVVM.

I didn't anticipate how much weight the code snippet would bear

But that's the meat, right? And I'm sorry it did not match the label.

@davidortinau

It seems like that's the direction of most comments here, wanting to discuss what we call and label things and how we use terms. I would dearly love your input on this, since I do much of the communication and want to make sure I'm indeed adding clarity and not generating confusion.

I'm not sure what's left to add from my side. I think I expressed my position loud and clear :-). If you're going to implement MVU, you will push at an open door. If it's what can be assumed by looking at the snippet in the announcement post and the Comet repository, feel free to do so – but _please_ stop calling it MVU.

Thanks.

As Don was mentioned in this thread :-) - CC: @dsyme

I don't understand why this is being called MVU, when it isn't. It might be a great paradigm and work just great here - why not come up with a suitable term that fits the paradigm and doesn't confuse?

@aspnetde what left from your side? A lot I suppose :).
I read some parts of your thesis. I have to say that I liked it. I also read the book from Don Syme about F#. I like functional programming. From my experience its concise, but difficult to grasp (understand). Readability is very important part of the development life cycle. Lot of the time is actually spent on reading code. And recursion is write only. You can write it once, but almost no one can read it (similarly to regexp).
In the past I tried Redux with Angular during my prototyping/research time in the company. Is it a half Elmish approach? It was a valuable experience. I learnt that I have to take care to not mutate the state, and as a result I will don't have to remember the whole stack, where exactly the state can suddenly change.
I understand the benefits of immutability, but I saw a presentation with Erik Meijer who suddenly tore apart a teddy bears head, to show us, that the real world is mutable.

So what I would like to point out: Isn't our natural thinking against these paradigms? What is your experience?

I have a lot of experience with XAML/C#/MVVM, so I'm wondering why Don Syme considers XAML unnecessary.
From my experience it helps to separate concerns (UI, presentation, business, etc. logic). I'm not really sure whether these DSLs (C# markups) and MVU are helping to improve the code quality in the long term. Not experienced/not caring developers will mix the responsibilities. I need also more experience with MVU pattern, to understand it correctly, but you tried both of these paradigms and it is very valuable for the whole community.
Please share as much as you can. Thanks @aspnetde!

Thank (all of) you very much for your understanding

@davidortinau maybe there was an misunderstanding here, I am totally for choice and leaving it to everyone to choose for themselves what pattern/paradigm to use. I was just trying to say, that we should name things correctly. As everyone in software development knows naming things is one of the hardest things to do, but if there are well defined things named already we shouldn't start reusing those names for things that they are not.

Miss communication Miscommunication is one of the biggest problems in our world today, I think as a community, as contributors to a project, as a leading project we should help everyone in understanding things and should also be open to criticism and admit mistakes and get together to fix that.
In this case I think using wrong wording needs to be fixed and for that to happen I'd love for this project to
a) understand that MVU is the wrong name for what we are talking about here
and b) to find the right term to describe what we are trying to establish here
and then c) update everyone and start using that new name

I think we are still at a point we're we can still go back and fix it. Let's do it right, the worst thing that could happen is that the XF/Maui community understands MVU as something else than the rest of the world.

That being said, I am a big fan of MVU and I also love MVVM, and I think the fluent MVVM approach (I don't have a better name yet) as in Comet and what has been presented so far is great and helps a lot of devs and I will support it, I just think we should fix the naming.

Edit: miss communication dropped out of the contest.

I understand the benefits of immutability, but I saw a presentation with Erik Meijer who suddenly tear apart a teddy bears head, to show us, that the real world is mutable.

@tomasfabian this is wrong.

You have to start to see the world as a series of events, that's what it actually is (no I don't want to start an event sourcing discussion here).
What happened to the teddy bear is only that a new event was added to its state, the event in this case is "ripped of head". And as you than can realize once an event happened you can't revert, as in you can't just undo or delete what happens. To get the head back onto the teddy you'd need a new event called "sewed head back on body". 😉

Discussing the benefits or not of FP and MVU is IMHO off topic here. This issue was, I thought, just about the potential for miscommunication and accurate naming.

@isaacabraham maybe you are right, and I apologize for it. It is my fault. I know that naming things is important, but on the other hand the issue's title is "MVU might not be what you think it is". So it is hopefully a little bit more broad topic than naming things.
Thank you, Tomas

@tomasfabian I'd be super happy to chat with you about the pros and cons of MVU, FP or whatever, real or imaginary 😊 Just don't think that this is the appropriate forum for it.

@davidortinau
As far as what language features and architecture changes would be helpful, hopefully I can contribute with some suggestions:

* The new Keyword and other syntactic noise. *
Unlike Dart or Kotlin, C# is probably stuck with a required new keyword forever, as making it optional is a breaking change and an unpopular proposal even as a per-file opt-in directive. So in lieu of that, maybe an official (and maintained) static class (or a static class per MAUI view namespace) containing static methods that just wrap constructors and initialize any init-only properties, if any, at least for the core set of MAUI view objects. Then we can put a using static directive at the top of our view code .cs files and then call the methods without the syntactic noise of new. This would reduce the clutter and noise of C# view functions a bit. Of course these static method constructor wrappers could be auto-generated by the community (I've done something similar for Xamarin.Forms to use with CSharpForMarkup), but it would be nice to have an in-the-box set of them maintained by the MAUI project.

Additionally, any C# language proposals that would help reduce syntactic clutter or noise in large expression trees (as is common in MVU/Comet/CSharpForMarkup view functions) would greatly help. C#9 has gone a LONG way in this regard to improve the M and U parts of MVU but the V part is still a pain point syntax wise.

* Extension properties *
I know the "extension-everything" proposal is on hold for now, but one thing that could be helpful for MVVM-with-C#-markup (e.g. CSharpForMarkup with Xamarin.Forms), would be extension properties. With CSharpForMarkup, every helper had to be implemented using an extension method, but in some cases an extension property (that is usable in the object initializer), would look a lot better:

// 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",
    };

This only really applies to mutable view object trees, as in MVVM with C# for markup. For MVU or other functional UI architectures this is not applicable as the view objects are immutable. In those cases a fluent extension method is still more appropriate.

* Be less opinionated (or low-level if you prefer) about state management *
I think one of the biggest barriers to entry to implementing MVU on top of Xamarin.Forms was the lack of two essential components: the lightweight object graph that the view functions could return, which the framework could "render" into actual components (with their platform-specific representations, etc...). And the second piece is a diffing engine that efficiently updates the heavyweight platform specific views by looking for differences between one return value of a view function and another, including a way to do diffs efficiently by doing partial diffs, etc...

It sounds like MAUI is now providing those two essential pieces, which is great! However, it appears at least on the surface level to be tied very closely to an opinionated way of managing state that some in the MVU community would say is closer to MVVM than MVU or similar "functional" UI architectures. I think my preference would be to keep the two essential pieces I mentioned above (lightweight view object graph and efficient diffing engine), and marry it with a lower level component system that MVU or Comet could be efficiently layered on top of, per the developer's choice. Maybe that's already the goal, and I'm not seeing it? If so, I'd love to see more discussion of that with at least some basic examples.

@aspnetde why did you deleted your post?

@tomasfabian

From my experience it [MVVM] helps to separate concerns (UI, presentation, business, etc. logic)

Yes, it does. I've made some good experiences with large Xamarin.iOS and Xamarin.Android applications built with MvvmCross. Although I very much prefer libraries over frameworks today, I think all of those projects (some with six-figure LOC) have been a success, technically as well as from the business perspective.

I think that MVVM especially does a good job when it comes to scale an application. Especially in mobile, where we are forced to ship monoliths, it helped us to refactor our apps into independent modules after they passed a certain size.

Isn't our natural thinking against these paradigms ([MVU])? What is your experience?

I don't think so. Take your experience with Redux for the storage and imagine your whole application to benefit from its advantages. While it appears to be more complex from a first glance, in my experience it is much more simple to understand and work with. As @forki often points out, it's almost boring because the unidirectional dataflow makes it clear what happens all the time.

I'm not really sure whether these DSLs (C# markups) and MVU are helping to improve the code quality in the long term.

While both MVU and MVVM have different advantages, both also have different drawbacks.

Despite considering our MVVM projects being successful, my team and I lost some hair over debugging them. In one project in particular we started to suffer from complexity that was caused by lack of experience from new team members, and misunderstandings – as you already pointed out. I think that's less likely in MVU when applied strictly, because it defines the boundaries of how things work so narrowly, that it's almost harder to break out of that and build things in a wrong way, than the other way around.

For MVU I see two major problems. First: Scaling. Many are advocating for a single program. I am sceptical here (and think multiple programs/modules would be a better way). Second: Right now, a thing like Fabulous sits on top of Xamarin.Forms. So it's an abstraction layer on top of an abstraction layer on top of an abstraction layer on top of iOS/Android. That's a huge amount of complexity. So you not only deal with unsolves bugs no one cares about, but it's also a more or less tedious and unpleasant job to update one abstraction layer (Fabulous) when the other (Xamarin.Forms) changes.

That's where I would see a big chance for MAUI. I honestly would love to see the Fabulous maintainers join forces with Microsoft here. And I really hope that Microsoft will not ruin it, as other parts of the org have done in the past.

Thomas

When I was reading the official announcement the other day, I was surprised what was presented there as MVU:

readonly State<int> count = 0;

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

As far as I am concerned, this is not MVU. I already wrote down some thoughts on why I think so here.

Don Syme, who, as I understand, spent several months of 2018 on implementing MVU on top of Xamarin.Forms and building what later became Fabulous, is a bit more diplomatic, but the bottom line is the same.

So, what's my point?

• I would love you to implement the real architectural pattern, no matter if in C# or F#. Reaching out to the people behind Fabulous could be a start here.
• If you are not interersted in that but have a clear vision on building on top what is available today as the Comet library, then please consider using a more appropriate name for that "app model." Invent something new. Name it MSMVU. Whatever. But don't sell apples for oranges.

Cheers!

Why would they name it MSMVU? Comet has been MVU, and it will remain so. And Maui is an MVU.

I think it's too early to say that .NET MAUI is or is not MVU

It's not about if MAUI will be MVU in the end. It's about the sample in the announcement blog that already raised so much confusion in the community. Basically I have to assume that the authors did not really look into MVU yet. Talking about "C# MVU" doesn't make this any better.

It does not cause any confusion whatsoever. Is just that some people can't handle it seeing C# doing MVU.

For what it's worth, SwiftUI (from which Comet takes most of its inspiration) tends to call its pattern MVVM, even though there's no explicit guidelines.
I haven't found any mention of MVU though.

@TimLariviere https://github.com/Clancey/Comet#key-concepts
Basically Comet called it MVU and already missing the point of the message loop that we have in older definitions of MVU

For what it's worth, SwiftUI (from which Comet takes most of its inspiration) tends to call its pattern MVVM, even though there's no explicit guidelines.

It's not even wrong, looking at the example at the beginning of this post here: https://nalexn.github.io/clean-architecture-swiftui/

I haven't found any mention of MVU though.

The same post discusses it briefly as well (as a combination of SwiftUI + Redux = TEA). Although it is then taking a strange turn to "Clean Architecture" 😄

Since I've been mentioned here, I will just say a few things.

• I think MAUI is great and I think learning about MVU as an architecture can be useful for people to understand MAUI.

• It's easy to get hung up about words, and we should probably all take a breather and try not to worry about it at this stage, since there's plenty of time to adjust the words that are used and I think the message about accurate terminology has been heard. Personally I think Elm has established that the unadorned, unqualified use of "MVU" means explicit messages, explicit update, functional models, functional view recalculation and differential update. But there are many variations of MVU and MAUI is one point in that spectrum (which covers all the way to MVVM as a sort of manually-incrementalized message processing system with implicit, pervasive mutable state). The SwiftUI communication is interesting from this perspective.

• I notice people tend to have very strong beliefs and opinions in this area and can take things quite personally. I know what that's like, and like programming language design I think all points in the space have pros and cons. I'd encourage everyone to try out, use, learn, share and work together to make the best range of technologies possible.

@dsyme
I think the proper term for the Comet/MAUI architecture is a variation of unidirectional data flow (or UDF), but not MVU as MVU is itself a very specific variation of UDF. MAUI/Comet certainly qualifies as a UDF framework (as does SwiftUI), but it does not qualify as an MVU framework. There are several variations of UDF including MVU, Flux, Redux, React, etc... but it's a miscommunication to call Comet MVU when it is not at all MVU.

Unlike MVU the Model is mutable, and is mutated by code in the View function. Mutations are then observed, and views react to those mutations by re-rendering. It's still unidirectional because views aren't mutated, but there is no update function, no messages, and no message dispatching - thus, not MVU. It's closer to a unidirectional variation of MVVM.

@JeroMiya Thank you, do you have a reference for that terminology?

@dsyme I don't have a specific reference for it, but I first started hearing the term being used in the early days of React, specifically in reference to React itself and a few of the early patterns that emerged such as Redux and Flux. I remember an article that described a number of UDF varients (mostly in the React space), but I can't find it now.

That being said it's not a formal architecture - more like just the basic concept of the view being a function of the model, as opposed to the view being a stateful object tree that mutates in response to events. The UDF concept doesn't necessarily specify how the model is updated or if it's mutable or immutable. MVU extends the UDF concept not just to the view itself but also the process of updating the model. So in MVU the model is also immutable, and UI state changes are represented as commands that produce a new models, which trigger new views.

It's not a new concept of course - even before React most server-side web frameworks like Asp.Net MVC, Rails, even PHP technically count as unidirectional. It just wasn't common for mainstream SPA frameworks and client-side UI frameworks before React came along.

@dsyme I don't have a specific reference for it, but I first started hearing the term being used in the early days of React, specifically in reference to React itself and a few of the early patterns that emerged such as Redux and Flux. I remember an article that described a number of UDF varients (mostly in the React space), but I can't find it now.

That being said it's not a formal architecture - more like just the basic concept of the view being a function of the model, as opposed to the view being a stateful object tree that mutates in response to events. The UDF concept doesn't necessarily specify how the model is updated or if it's mutable or immutable. MVU extends the UDF concept not just to the view itself but also the process of updating the model. So in MVU the model is also immutable, and UI state changes are represented as commands that produce a new models, which trigger new views.

It's not a new concept of course - even before React most server-side web frameworks like Asp.Net MVC, Rails, even PHP technically count as unidirectional. It just wasn't common for mainstream SPA frameworks and client-side UI frameworks before React came along.

@JeroMiya thanks for this, this is exactly how I understand MVU.
I would even say that one of the oldest and still majorly use application that uses and examples MVU in its best Form is MS Excel.

@dsyme reading your comments I get the feeling that you are referring to MAUI as the term for the discussed architecture (CSharpForMarkup with MVVM).
Please clarify for me that this isn't what you understand MAUI to be or if it is.
From my understanding MAUI is just the next MS Application Framework to replace XF at some time in future.

I really like the way this issue and it's comments are going. Thanks for everyone participating. Maybe together we can get all the different architectures as possible flavors for MAUI established and named properly.

@dersia Thank you! Just a note from my own experience with CSharpForMarkup: it's a bit lower level than MVVM - more of a set of extension methods and utilities to make C# markup more streamlined and nicer looking. You can certainly implement an MVVM pattern with it as it has helpers to make ViewModel bindings easier but what I ended up doing is implementing all of my view logic in Redux instead of ViewModels. Just needed to add a few extension methods to bind view properties to state selectors, which are just Func<StateType, ChildStateType> I pass into Select and DistinctUntilChanged operators on the Redux state store, which is an Observable<StateType>. Not quite unidirectional data flow but I didn't have a mature way of doing UI object tree diffs and view functions like Fabulous does now.

Some time ago the REST police tried to shove it down our throats that we all do should not be called REST. Everybody still calls it REST today and we‘re all still alive and well. 😉

@bitbonk the REST community gave up the term because it became ever more useless as more and more things were thrown into the mix. They now use “hypermedia” to refer to REpresentational State Transfer. REST, today, now really only means “not SOAP” or “JSON over HTTP,” neither of which succeeds in communicating its core idea. The commenters here are hoping to avoid the same fate for MVU.

@davidortinau @tomasfabian, I have yet to see an example of MVU on MAUI. I will try to work out an example tonight. I just did something similar for WinForms here. I assume it shouldn’t be too hard.

@JeroMiya Thank you, do you have a reference for that terminology?

@dsyme, I think it originated with React Flux, but they pointed to game architectures, i.e. Doom 3. I think I remember discussing this with @TIHan back when it was first presented.

• 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/unidirectional-data-flow

Here's my attempt at a C# example. I don't have MAUI available to try this as a real example. There's no preview, is there? Anyway, this is a rough translation of the idea.

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);

I once briefly tried something similar, except for the view part. With Records coming to C# 9 this will be even more reasonable.

I am relatively new to MVU, and I probably have very little experience using it compared to many of you. But the MVU concepts have definitely caught my interest, and I am enjoying it. I am very glad to see that C# developers are given a framework to help develop in the MVU pattern.

I totally agree that MAUI MVU is not the typical MVU and its has an huge influence from SwiftUI. Its main author Clancey himeslef had made it very clear in almost all of his sessions. We all know that Redux is highly influenced from MVU, so is SwiftUI, Flutter and many other frameworks. None of them are pure MVU.

But I am sure, we all agree that the closest architectural pattern for all these frameworks are MVU. Thats the reason why people refer it. And remember we are talking about a blog title for a framework that's gonna be released another one and a half year from now.

And if you say that people are getting angry about for this blog title. I don't think we should really worry about them. The community still needs to keep going. Lets spend our energy to make this framework better. Not worry too much about the little details.

But I am sure, we all agree that the closest architectural pattern for all these frameworks are MVU. Thats the reason why people refer it.

Dogs, horses, cats and chimps are all very close to each other. From now on I'll refer to all of them as cats.

:) Well you dont have to. But let me tell you something: Cats, Tigers, leopards etc are called as cats. And I am glad you brought it up. Coz thats exactly the case here.

@aspnetde : Thomas, with all that said. I would need to say that your original MVU blog is one of the best article that explains the concept very clear and precise. I have learned a fair bit from it. Thank you

@libin85 there is exactly the problem. You started to enumerate things that are actually in one category and ignored the ones that are not. With putting the MAUI sample into MVU category you basically put a chimp into cats category.

The are similarities with MVU implementations, like an immutable view. But there are clear differences like, there are is no message loop and no explicit update function. The model is mutated directly in the View. This is something people explicitly didn't want when they came up with MVU. In some languages it would even be impossible to do that - that's why MVU emerged. And why it became popular. Now we should be careful if we remove those properties from our definition of MVU.

@forki : I am not against whatever you said. Infact it's those points that you brought up in the last comment that we need to discuss as a community and not title on a blog post. That's my point. That's a positive thing to discuss and the framework will gain from it.

I agree that the name is a little detail that should not distract from more important aspects. However, the reason I brought it up is that I personally do not see MAUI as a community effort where common sense eventually will lead to a commonly agreed solution. It's a Microsoft product where final decisions are being made behind closed doors. I am here in my capactiy as a customer to raise my concerns.

But I am sure, we all agree that the closest architectural pattern for all these frameworks are MVU.

@libin85 I disagree this is the closest architectural pattern. MVU is a set of constraints against what looks more generally like MVP, or Model View Presenter. MVVM is similar, taking a different direction in that its Presenter is a ViewModel with data bindings. MVP itself is a constrained form of MVC. I think it's fairly safe to say these are all descendants of MVC and even MVP, but to say that MVU applies to SwiftUI, Flux, etc. is to make MVU a meaningless term.

I agree that the name is a little detail that should not distract from more important aspects.

No, names are important. They are difficult, both to establish and to retain their meaning. See also REST, which I discussed above. REST is so abused that it is no longer meaningful except as a marketing jargon term. I'd like to not see that happen to MVU, especially when there are existing terms for what MAUI's "MVU" provides.

For what it is worth, I think the MAUI "MVU" is a nice alternative to the MVVM option. Just like with REST, you don't have to do the definitional thing to make something useful and good. Just please don't muddy the name with alternatives that clearly deviate from a well-defined and established pattern. After all, MVU would _also_ be a nice alternative to the MVVM and Comet options.

For what it is worth, I think the MAUI "MVU" is a nice alternative to the MVVM option. Just like with REST, you don't have to do the definitional thing to make something useful and good, just please don't muddy the name with alternatives that clearly deviate from its definition.

FULL ACK.

Why would they name it MSMVU? Comet has been MVU, and it will remain so. And Maui is an MVU.

@saint4eva they are "marketed" as, but by definition not, MVU.

I agree that the name is a little detail that should not distract from more important aspects.

No, names are important. They are difficult, both to establish and to retain their meaning. See also REST, which I discussed above. REST is so abused that it is no longer meaningful except as a marketing jargon term. I'd like to not see that happen to MVU, especially when there are existing terms for what MAUI's "MVU" provides.

For what it is worth, I think the MAUI "MVU" is a nice alternative to the MVVM option. Just like with REST, you don't have to do the definitional thing to make something useful and good. Just please don't muddy the name with alternatives that clearly deviate from a well-defined and established pattern. After all, MVU would _also_ be a nice alternative to the MVVM and Comet options.

I agree with most what you said, but I think "Maui MVU" is still as bad and confusing. I would probably go with "Maui MVP" or MVC. Both work and is closer to what is presented in the blog post than MVU.

Edit add:
I am even not sure where the proposed version lives. I mean logic in MVVM lives in the ViewModel, with MVU it lives within the update-function and with MVP it lives in the Presenter and with MVC it lives in the Controller.

Is there going to be a View where everything lives in? Or does it all live in just some class named by the Domain Model what serves the view, logic and model? Are models supposed to be separate classes (types) or records?

I think this is for me the major pain point here, I have no clue how it is "presented" and therefor I can't see there to be an update, model and view function.

Out of the box, it seems to me that MAUI is a little lower level than the patterns discussed so far - really just the Model (or State) and the View portion of those other patterns. Something you could perhaps build on to implement those other patterns (although state management is a bit opinionated).

So for example, if the T in State<T> is a ViewModel-like class, and you add a separate set of data model classes, then what you'd end up with is something like MVVM with a unidirectional view.

On the other hand, if you add a Redux-like state management system and plug the Redux state model in as your T in State<T>, then what you end up with is something very close to MVU, although not quite as fully integrated as a traditional MVU like Elm/Fabulous. Maybe you could hide MAUI views behind the MVU framework, like Fabulous does with Xamarin.Forms?

I'm not sure how you would implement an MVC or MVP pattern over MAUI. As a rough first pass, I'm thinking maybe if you created a separate class that exposes "actions" to the view function. For instance, say you had a MAUI confirmation dialog, and your "controller" class has an "ClickOK" method and a "ClickCancel" method. The MAUI view would forward click events from the view to the controller, which would either generate a new model or mutate the existing model.

@JeroMiya I agree, definitely using Redux pattern can make it closer to MVU and keeps architecture a lot less opiniated. I am a happy user of React-Redux, React-Hooks, ReactiveX and lately for Blazor Apps :heart: Fluxor :heart: . @mrpmorris may contribute this conversation.

Here's my attempt at a C# example. I don't have MAUI available to try this as a real example. There's no preview, is there? Anyway, this is a rough translation of the idea.

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);

Would this incur more of a performance cost for updates than in the Microsoft sample? In this model, if I understand, a new view would be instantiated containing all of the UI elements, as opposed to, in the MS sample, leaving the existing view elements in place and merely updating the value of the label (an incurring whatever re-sizing cost this could have).

This difference seems to be one of the core differences driving this discussion around naming, and so I'm curious if in the traditionally defined MVU architecture there are other technqiues for efficiently updating UI, and if so, are they implemented at the level of the rendering engine?

@markmccaigue in regards of performance: often MVU systems come with a virtual view (or virtual DOM in the case of html) and a diffing engine. So after diffing DOM with virtual DOM the framework only needs to apply a patch to the DOM. This is usually very very efficient, especially if you work with immutable data structures.

Hello!!

I'm going to close this issue for now.. I'd like to make this a discussion but github doesn't want to make that work :-/

If anyone wants to continue this conversation please create a discussion item and then references this issue