[Enhancement] Create a pure MVU framework

[adospace]

Summary

Today MVU pattern represents a great alternative to the more traditional MVVM approach: React Native and Flutter prove that. Looking at the future, MAUI should consider MVU as a first-class citizen.

API Changes

Create a brand new hierarchy of types without BindableObject, DependencyProperty, Style, Template, etc whose only purpose is to serve the MVVM pattern. MVU doesn't need any property change callback, styles are applied at compile time and there isn't any resource/template lookup.
In other words, MVU should not be just a layer over the MVVM framework.

Intended Use Case

MVU allows a real, fast hot reload of the complete application (not just the current page), preserving the state between iterations.

BTW I'm really excited about MAUI !

[Nirmal4G]

I think MVVM (XAML based) would be layered on top of MVU (C# based). Current state is building up the prototype from XF codebase and then they might switch the layers. Some design information from the team would be helpful.

[FruitTreeAlchemist]

I think MVVM (XAML based) would be layered on top of MVU (C# based).

As long as the additional abstractions do not add too much performance overhead...

[Nirmal4G]

If designed right, then, it won't add too much overhead.

[charlesroddie]

Create... types without BindableObject, DependencyProperty, Style, Template, etc whose only purpose is to serve the MVVM pattern.

Yes! This is really a subtractive request. These types are very problematic because they are untyped string-based things from the .net days before generics.

I think MVVM (XAML based) would be layered on top...

Yes! The UI types are the primary things, and markup language (XAML) is a layer on top, and any binding or navigation mechanism (inc. MVVM) can also be a layer on top. This keeps the core library pure and clean - and thereby more efficient and less buggy.

[adelarsq]

How F# will work on top of that MVU? Will be possible to use pure F# (something next to the ELM way) or will need some C# boilerplate?

[charlesroddie]

@adelarsq Currently Xamarin.Forms involves various .Net View classes and you can instantiate these perfectly well from F#. There is also a "pure" approach of Fabulous which analyzes the Xamarin.Forms codebase and generates a model of it for use in an Elm-style approach. So you can do both already, and will continue to do so.

C# helpers are being added to XF and you would probably ignore them using F#. This approach is opt-in and will hopefully remain so that the main View classes remain clean for intellisense. The C# helpers may end up helping F# as they will get more people using code to write UI and may result in better tooling for that: previews and hot reload.

Writing helpers suitable for F# is very easy. See this example.

[GiampaoloGabba]

c#9 is looking very promising for MVU-like style :)
https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/

[PureWeen]

One of the big goals of slim renderers is to enable these types of scenarios

#28

The slim renderers will give us a UI agnostic layer of renderers that can easily be reused with blazor/mvu/maui/the hot thing that comes out next week

If you want to start playing with some spikes of MVU
https://github.com/Clancey/Comet

That will help shape where we go with this

[Clancey]

@adelarsq Currently Xamarin.Forms involves various .Net View classes and you can instantiate these perfectly well from F#. There is also a "pure" approach of Fabulous which analyzes the Xamarin.Forms codebase and generates a model of it for use in an Elm-style approach. So you can do both already, and will continue to do so.

C# helpers are being added to XF and you would probably ignore them using F#. This approach is opt-in and will hopefully remain so that the main View classes remain clean for intellisense. The C# helpers may end up helping F# as they will get more people using code to write UI and may result in better tooling for that: previews and hot reload.

Writing helpers suitable for F# is very easy. See this example.

It will be easy to port Fabulous to the new Maui Architecture! It can talk directly to the new layer rather than wrapping Xamarin.Forms. Which will make it way more efficient.

[JeroMiya]

Yeah, although I greatly appreciate the effort the dotnet team went into supporting modern functional code-first UI patterns, I feel like something went a little wrong along the way trying to implement MVU in MAUI. A large part of MVU is to eliminate the UI framework and its types entirely from the UI state and UI logic. There are no required base classes for model types or message types, and the update function is a simple function from (model, msg) => model. That's a feature of the architecture.

That's almost completely gone from MAUI's "MVU" implementation. For the purposes of optimization and simplicity, they have somehow managed to take MVU and turn it into MVVM, with mutable state and not just state change but now also state read events. I think MAUI has somewhat missed the point of MVU and functional reactive UI, or why developers might choose this model beyond just the ability to do MVVM with code-based view layouts.

I think there were two primary drivers of this. One is perhaps some baggage from Xamarin.Forms, XAML, and MVVM. The other is performance. It seems like without a templating engine to track property values from parent components to child components (like React), or a Component model to isolate UI diffs in the tree (Flutter model), MAUI had no choice but to diff the entire UI tree. And of course that's slow. I'm not sure what the solution to that should be, but I think I would have considered other options before the current MAUI/Comet architecture.

Maybe if MAUI were a totally greenfield framework, then the view objects could be simple immutable models themselves, and the lower-level mutable UI objects hidden behind the scenes. The view function would return immutable view objects. While new expressions could be used in a view function, most components in the UI tree would be constructed with static methods instead of constructors. Thus, because the view objects themselves are immutable, the static methods could safely memoize or cache or buffer their return values based on the parameters to the method. Then the diffing engine could short-cut an entire UI subtree in the diffing algorithm if it found the old view and the new view were referentially equal (as they would be with memoization).

Going even further, if view objects were allowed to optionally implement an interface that would allow the view object to report its parameters (or a hashcode of all of its parameters together, etc...) then the diff engine could short circuit sub-tree comparisons even without caching, memoization, or multi-update buffering.

[akhanalcs]

Commenting to try to get attention of MAUI team on this. :)

[thongdoan]

In MVU:

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

I think the framework can't invoke this method without reflection (search methods have BodyAttribute), reflection is slow, to make MVU faster please consider to use Interface or virtual methods. React, Flutter work well without reflection.

In React, functional components and hooks are super useful, MaUI please support it:

• It’s hard to reuse stateful logic between components Generally when you use HOC or renderProps you have to restructure your App with multiple hierarchies when you try to see it in DevTools, Hooks avoid such scenarios and help in clearer code
• Complex components become hard to understand Often with classes Mutually unrelated code often ends up together or related code tends to be split apart, it becomes more and more difficult to maintain. An example of such a case is event listeners, where you add listeners in componentDidMount and remove them in componentWillUnmount . Hooks let you combine these two
• Classes confuse both people and machines With classes you need to understand binding and the context in which functions are called, which often becomes confusion.

(Source: https://stackoverflow.com/questions/53062732/react-function-components-with-hooks-vs-class-components)

[Clancey]

In MVU:

[Body]

View body() => new StackLayout

{

    new Label("Welcome to .NET MAUI!"),

    new Button(

        () => $"You clicked {count} times.",

        () => count.Value ++)

    )

};

I think the framework can't invoke this method without reflection (search methods have BodyAttribute), reflection is slow, to make MVU faster please consider to use Interface or virtual methods. React, Flutter work well without reflection.

In React, functional components and hooks are super useful, MaUI please support it:

• It’s hard to reuse stateful logic between components Generally when you use HOC or renderProps you have to restructure your App with multiple hierarchies when you try to see it in DevTools, Hooks avoid such scenarios and help in clearer code

• Complex components become hard to understand Often with classes Mutually unrelated code often ends up together or related code tends to be split apart, it becomes more and more difficult to maintain. An example of such a case is event listeners, where you add listeners in componentDidMount and remove them in componentWillUnmount . Hooks let you combine these two

• Classes confuse both people and machines With classes you need to understand binding and the context in which functions are called, which often becomes confusion.

(Source: https://stackoverflow.com/questions/53062732/react-function-components-with-hooks-vs-class-components)

This is something we were talking about on my livestream today. That api is not 100% set in stone. However the reflection hit is minimal. And also can be removed with source generators.

[thongdoan]

This is something we were talking about on my livestream today. That api is not 100% set in stone. However the reflection hit is minimal. And also can be removed with source generators

If you only have few Views, the reflection hit is minimal, but if you have a lot of views, i think it is not. The source generators is great but will it affect to build speed.

https://stackoverflow.com/questions/40927442/xamarin-build-times-extremely-slow

Now you maybe make it slower

[Clancey]

The attribute is also not required. It's just syntax sugar. new View { Body = ()=> ...} also works.

[shirshov]

Can I plug my own work here? Please tell me if it's inappropriate, I'll remove this comment.

I'm writing an MVU library for Xamarin.Forms, and much of what's disussed in this issue
is addressed in one form or another in Laconic: https://github.com/shirshov/laconic

Replying to @JeroMiya, who wrote on 25th of May:

A large part of MVU is to eliminate the UI framework and its types entirely from the UI state and UI logic.
There are no required base classes for model types or message types,
and the update function is a simple function from (model, msg) => model. That's a feature of the architecture.

With Laconic I went the React way and implemented a virtual view tree. The app code doesn't manipulate
actual views, but instead declare what should be shown on screen given the current state. This
declaration function is 100% pure. Updates to model are pure functions too.
A model is called a state in Laconic (like in Redux), and there are no special requrements for it.
But it better be immutable.

MAUI had no choice but to diff the entire UI tree. And of course that's slow.

Well, Laconic does diff the entire tree. But since the tree is virtual, essentially a tree of dictionaries,
the difing is very fast. And there's no Reflection. I have a performance demo in the repository.

[MappingSteve]

@shirshov - glancing at your repo, that sounds very much like what I am looking for in an MVU approach. My goal is to completely remove any need to be dependent on MVVM.

(Then maybe add an MVVM layer back in on top. If that turns out to be worth it.)

[JeroMiya]

Interesting. I had always figured some performance issues with large complex trees to just be part of the MVU package. Is the tree of dictionaries approach fast enough for non-extreme cases? What would be the cutoff?

[nabond251]

Indeed, interesting. Would you be planning to carry this on to Maui when it gets here? Great work.