[Enhancement] Does it provide CSX syntax, just like JSX in React.js?

[DingpingZhang]

Summary

I want MAUI can provide the CSX syntax, just like JSX in React.js.

As we know, Declarative syntax is advantageous for defining the UI structure, while imperative syntax is suitable for writing business logic. The JSX syntax is a combination of the two, and two styles can be mixed in the same file.

There are generally two styles of declarative syntax for defining UI: json and xml. The current MVU syntax is biased towards json style, just like flutter. But I'm afraid to look at the "thousands of" closing brackets at the end of flutter code :(

You have to use a plugin to display the closing tag in the form of comments, because you can't find the corresponding close tag (CSharp becomes not "see sharp"), like this:

...
        } // TextBox
      } // Button
    } // StackPanel
  } // Grid
} // MainWindow

Intended Use Case

Current MVU syntax:

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

Use CSX syntax:

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

[Happypig375]

Is that VB XML literals?

[saint4eva]

Summary

I want MAUI can provide the CSX syntax, just like JSX in React.js.

As we know, Declarative syntax is advantageous for defining the UI structure, while imperative syntax is suitable for writing business logic. The JSX syntax is a combination of the two, and two styles can be mixed in the same file.

There are generally two styles of declarative syntax for defining UI: json and xml. The current MVU syntax is biased towards json style, just like flutter. But I'm afraid to look at the "thousands of" closing brackets at the end of flutter code :(

You have to use a plugin to display the closing tag in the form of comments, because you can't find the corresponding close tag (CSharp becomes not "see sharp"), like this:

...
        } // TextBox
      } // Button
    } // StackPanel
  } // Grid
} // MainWindow

Intended Use Case

Current MVU syntax:

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

Use CSX syntax:

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

Current MVU syntax is better.

[DingpingZhang]

Is that VB XML literals?

@Happypig375 What does it mean?

[Happypig375]

@DingpingZhang This issue reminds me of this

[libin85]

I find the current style much easier and clutter free. It also means one less thing to learn.

[DingpingZhang]

Current MVU syntax is better.

@saint4eva This is just syntactic sugar. Some people like it, while others don't. But I think the popularity of React.js proves its value. The current style can still be retained, this is just one more choice.

[DingpingZhang]

@DingpingZhang This issue reminds me of this

@Happypig375 Thank you for the infomation. I am not familiar with VB, and I think React.js should use this style earlier.

[codri]

There is also the option of using Elm syntax since MVU is inspired by Elm.

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

But it's highly likely, from what I've seen in the presentation, that C# can pull a Dart/Kotlin and make the new keyword optional(it would be interesting to see what changes to the compiler will have to be made to make this work), so it could look like this:

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

[dhindrik]

The goal is that you should be able to use Blazor, #45.
And think your suggestion is similar to what you can do with Blazor.

Here you can read some examples of how that can look. https://docs.microsoft.com/en-us/mobile-blazor-bindings/.

[DingpingZhang]

The goal is that you should be able to use Blazor, #45.
And think your suggestion is similar to what you can do with Blazor.

Here you can read some examples of how that can look. https://docs.microsoft.com/en-us/mobile-blazor-bindings/.

The Blazor syntax looks like Vue.js, not React.js (JSX). It's still MVVM, just put the view and view model in one file, and the XAML and C# are still separate.

I remember that XAML(WPF) is also allowed to insert C# code.

[saint4eva]

Current MVU syntax is better.

@saint4eva This is just syntactic sugar. Some people like it, while others don't. But I think the popularity of React.js proves its value. The current style can still be retained, this is just one more choice.

If you must need the second option, why not just the MVVM app model? It will be supported also. So the MVU app model shouldn't be introducing additional XAML like syntax. The essence of MVU is writing the UI in C#

[saint4eva]

There is also the option of using Elm syntax since MVU is inspired by Elm.

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

But it's highly likely, from what I've seen in the presentation, that C# can pull a Dart/Kotlin and make the new keyword optional(it would be interesting to see what changes to the compiler will have to be made to make this work), so it could look like this:

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

C# Source Generator can do that - removes the "new" keyword.

[dersia]

A) there is already something called csx and it's called c# scripting
B) Can we please stop calling something MVU that isn't? This is making dev believe they understand MVU and start comparing apples and oranges.
C) I don't mind your proposal, I even think it could make it easier for web-devs to start using Maui, but I think this is something that should be developed and maintained by the community

🙂

[JeroMiya]

If you want to eliminate the new keyword in code-based UI layouts, the trick is to create static methods with the same or similar name as the object you want to construct, and have it pass its arguments to the constructor for you and return the new object. Then use a using static NamespaceName.StaticClassName; directive at the top of your UI's .cs file. This will allow you to replace a new expression with the static method you created.

It's best to write a code generator that creates these functions for you, otherwise you'll be spending a ton of time writing and updating these static methods.

[j-francisco]

Current MVU syntax is better.

@saint4eva This is just syntactic sugar. Some people like it, while others don't. But I think the popularity of React.js proves its value. The current style can still be retained, this is just one more choice.

If you must need the second option, why not just the MVVM app model? It will be supported also. So the MVU app model shouldn't be introducing additional XAML like syntax. The essence of MVU is writing the UI in C#

The essence of MVU isn't about writing the UI in C#. Just like the point of MVVM isn't about writing the UI with XML syntax. MVU is a pattern for structuring an application. The syntax you use in the view is not the main point.

I like the idea of a JSX-style way of writing the views. As a view gets bigger, it's often easier to read and understand that way. In React you have the option to write out the javascript or use JSX, and almost everybody ends up using JSX.

[dersia]

Current MVU syntax is better.

@saint4eva This is just syntactic sugar. Some people like it, while others don't. But I think the popularity of React.js proves its value. The current style can still be retained, this is just one more choice.

If you must need the second option, why not just the MVVM app model? It will be supported also. So the MVU app model shouldn't be introducing additional XAML like syntax. The essence of MVU is writing the UI in C#

The essence of MVU isn't about writing the UI in C#. Just like the point of MVVM isn't about writing the UI with XML syntax. MVU is a pattern for structuring an application. The syntax you use in the view is not the main point.

I like the idea of a JSX-style way of writing the views. As a view gets bigger, it's often easier to read and understand that way. In React you have the option to write out the javascript or use JSX, and almost everybody ends up using JSX.

I think this feature would be really great for DataTemplates!

[JeroMiya]

I think I'd prefer to use a code-in-template syntax like Razor/Blazor than a template-in-code syntax like JSX/TSX. The main benefit of a code-in-template syntax is that multiple code-in-template syntaxes can exist side-by-side and can be driven by the community independant of the evolution of C#. For example, a true XML markup syntax (e.g. XAML) and an HTML markup syntax (e.g. Razor/Blazor) can both exist as third party code-in-template frameworks. If we picked one of them as a template-in-code framework, we'd be stuck with it and we'd have to use it for all applications whether the markup is an xml dialect or html. It's not likely we'd end up supporting multiple template syntaxes in the core C# language.

That being said, I would love to see a Razor/Blazor inspired code-in-template syntax as an alternative to XAML and MVVM bindings and list views, etc... Maybe tied in with the new shadow DOM and diffing engine in MAUI.

[dersia]

... The main benefit of a code-in-template syntax is that multiple code-in-template syntaxes can exist side-by-side ...

Think of this the other way around. Having multiple template-in-code, as you call it, side by side DataTemplate and also the DataTemplateSelector makes Templating a breeze. If you on the other hand had code-in-templates, then you'd either have to copy logic into each DT or fallback to the way it is today, code and template separate.

Just to make clear what I read when reading code-in-template, for me this sounds as VieModel-in-View or View-in-Viewmodel. If you were talking about code behind files, then this would be totally different story...

[JeroMiya]

@dersia I meant code-in-template in the same vein as Blazor or Razor syntax, in the sense that the template syntax allows for C# code to be inserted into the template using an escape syntax, like the @ symbol for Razor. With Razor, the developer can choose to have a code-behind if they want, or just have a @code section, etc.. or a bit of inline code - whatever is appropriate to the situation or the developer's preference.

Note that both code-in-template and template-in-code imply a UI framework like React, MVC, Blazor, or Flutter, where the UI is "rendered" (at least partially) multiple times (usually on a state change). This would be in contrast to XAML and MVVM, where the UI is instantiated once from the XAML, after which MVVM bindings, declarative behaviors, and code-behind mutate the UI after instantiation.

So, instead of a binding as you'd see in a traditional MVVM app, the view template simply renders values directly into properties of UI elements in the template. Instead of binding to an observable collection, a code-in-template framework would allow you to just use a for loop to dynamically add children to a parent component (like a panel or list view). Instead of a DataTemplate, you just have template syntax in the body of a for loop.

[dersia]

@JeroMiya can't you for that just use blazor mobile bindings? This is exactly what you are asking for...

[JeroMiya]

@JeroMiya can't you for that just use blazor mobile bindings? This is exactly what you are asking for...

Yep, just so. Just saying I think that solves the problem in a better way than a type of CSX syntax.

[dersia]

I agree, it solves your problem, but these are two different use cases and therefor it comparing apples and oranges 😉

Don't get me wrong, I am not a big fan of mixing Views and ViewModels, but if we can use this feature to replace code-behind files I do see a use case for it.
But again not talking of Views and ViewModels but Views + (c#) UI Logic (i.e. animations).

[JeroMiya]

@dersia Yeah, I think I understand what you meant. I think we are actually on a similar page, so maybe I should clarify:

I see a use case for integrated markup and templating with code. In many cases, using bits of C# code directly in the template (or bits of template in C# code), results in a cleaner, easier to understand layout. That sounds counterintuitive but in practice I think it's true. Is you say, it also avoids having some of the view code in one place (in an XML file) and some of the view code in another place code-behind. While you might still want to have a code-behind for more complex views, for simple views having them both in one file is sometimes easier to manage.

So, with that understanding, there are two ways to go about integrating a templating markup language (like XAML/HTML) with a general purpose programming language (like C#). One way is to template-in-code - that's the way JSX works. The JSX is a superset language using JS as a base, which has a way to toggle between code and markup. The other way is code-in-template, which is to start with a templating language, like HTML or XAML, and add a way to insert C# code snippets into it. Blazor and Razor are mature examples of this route.

Fundamentally, both routes have the same end result, the same use cases, and both solve very similar problems. I'm saying my personal preference is to go the route of Blazor mobile bindings, which is to let the developer inject C# code into the template. I think it works better for the ecosystem since it doesn't create a dialect of C#. Plus we already have one implemented in the mobile blazor bindings. That being said, if someone in the community managed to implement a CSX compiler plus all the tooling needed (VS Code, Visual Studio, Visual Studio for Mac, and Ryder extensions) I'd say more power to ya! :)