-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MVU might not be what you think it is #118
Comments
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? |
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.
So C# 9 would, while still be more noisy than F#, be good to go from my current point of view.
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. |
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. |
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.
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.
We have had extensive conversation and debate on the topic. Please don't assume, and I'll try not to as well.
@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. |
But that's the meat, right? And I'm sorry it did not match the label. |
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 :). 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. 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.
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. |
@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). |
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. |
@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 ** The 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 ** // 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 ** 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?
|
Why would they name it MSMVU? Comet has been MVU, and it will remain so. And Maui is an MVU. |
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. |
@TimLariviere https://github.com/Clancey/Comet#key-concepts |
It's not even wrong, looking at the example at the beginning of this post here: https://nalexn.github.io/clean-architecture-swiftui/
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.
|
@dsyme 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. |
@JeroMiya thanks for this, this is exactly how I understand MVU. @dsyme reading your comments I get the feeling that you are referring to MAUI as the term for the discussed architecture (CSharpForMarkup with MVVM). 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 |
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. 😉 |
@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. |
@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. |
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. |
FULL ACK. |
@saint4eva they are "marketed" as, but by definition not, MVU. |
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: 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 On the other hand, if you add a Redux-like state management system and plug the Redux state model in as your 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 ❤️ Fluxor ❤️ . @mrpmorris may contribute this conversation. |
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 |
As i see this and what the snippet look like to me is something I first found in React, then Flutter, then in SwiftUI. I'ts fine having any name for it. |
I haven't used Elm, but the essence of what I'm looking for, when I think "MVU", is what one does in React (at least as I understand it - I've only done limited work in React JS):
Its a "functional programming" paradigm. Avoiding the problems that MVVM has (in my experience), in layouts with complex inter-dependencies. Any inter-dependencies are resolved by the app developer in writing the tree. The renderer has a straightforward task. IMHO, Its easier to debug tree-writing code, than figuring out what went wrong where in the data binding. I'd rather do it that way, even if at first it takes more coding. Is that close to what is being considered? How can I get involved in MAUI MVU development? I've got years of (often painful) experience pushing Xamarin Forms to the limit. -- ToolmakerSteve |
I'm trying to make Full MVU library for Xamarin.Forms |
@shirshov - Can you compare-and-contrast your approach To Fabulous? And maybe say a little about how all these approaches compare to ReactJS + Redux or ReactJS + Formik? That's the closest tech that I am familiar with. (Formik seemed simpler for my purposes in JS than Redux, so I chose it over Redux.) |
MVU to me has always been the elm architecture. Using it has led to a fantastic developer experience where I've been able to write thousands of lines of code and ship without any production bug. I must echo the other ones here, it shouldn't be called MVU unless it's actually the same as elm's MVU. It bogs down the term and I wish companies instead strived to implement the real thing since that would be a gain for the industry. Microsoft should take responsibility, their actions end up shaping the terminology we use. It would make me sad if they ruined the term. |
When I was reading the official announcement the other day, I was surprised what was presented there as MVU:
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?
Cheers!
The text was updated successfully, but these errors were encountered: