Why was the default content in the Main Page/Window of a new WinUI3 app chosen?

[mrlacey]

The default WinUI3 app project templates (C# & C++) includes the following in MainWindow.xaml and MainPage.xaml.

    <StackPanel Orientation="Horizontal" HorizontalAlignment="Center" VerticalAlignment="Center">
        <Button x:Name="myButton" Click="myButton_Click">Click Me</Button>
    </StackPanel>

I appreciate that there was probably a desire to have some basic functionality in what is created by default, but why this specifically?

Is the intention that developers should remove all of the above from the generated app?

Using StackPanel as a top level container (within the Page or Window) is not something I see very often. Do you have research that shows this is common practice in shipping apps?

Having a StackPanel with only a single child element is rarely a good idea. Doesn't this set a bad example? Especially to new developers, for whom (presumably) this content is particularly targeted?

The StackPanel specifies the property Orientation="Horizontal" but this is irrelevant as there is only one child element. Was there a deliberate reason for specifying a property that has no effect on the rendered UI?

The name myButton_Click causes VisualStudio to report suggestion IDE1006 as a naming violation because the .NET naming convention is that functions should start with an uppercase character. Is this: an unintentional side-effect of the way the method name is based on the X:Name of the button; a lack of consideration for .NET conventions; or a deliberate break from conventions that will eventually be addressed in another way?

The same template pack includes a new Blank Page/Window option that includes an empty Grid as the only content of the Page/Window. Knowing why a Grid isn't used here too would help understand how these decisions were made.

Someone made the decision to use this XAML and giving us an understanding of why will help the community by:

• Sharing more of your knowledge about how XAML is used in the real world helps members of the community who want to contribute here and in other projects that are trying to help developers build Windows Apps.
• Shows that this wasn't an arbitrary decision. 😉

The following produces exactly the same output as the above but with the benefits of:

• Setting fewer properties.
• Not setting any properties that have no impact on what is rendered.
• Not including a StackPanel that is expected to be deleted by the developer.
• Including a Grid that it is expected would need to added by the developer.
• Not showing the bad pattern of using unnecessary container elements with a single child.

    <Grid>
        <Button
            x:Name="myButton"
            HorizontalAlignment="Center"
            Click="myButton_Click">Click Me</Button>
    </Grid>

As these templates weren't public at the time these decisions were made, it would also be great to understand how the decision to include this code was tested. Was it only reviewed internally or did you reach out to new and experienced developers to get their feedback as part of a user testing program?

[mrlacey]

To further expand on why this matters:

• If the code in the new project includes code that is expected to be deleted this means a few seconds work for every app that is ever created. Hopefully there will be lots of WinUI3 apps created and so this will add up to a lot. There needs to be a really good reason to be requiring effort that adds up to thousands of hours of developers time. It might not be the time of the person who created the templates but they are responsible for it. Imagine what could be achieved with a thousand hours of developer time. Is deleting unnecessary code the best way to spend it?

• Whether you intend it or not, the code that is included in the default templates is seen by many developers as being a recommendation and best practice direct from Microsoft. Please create the default templates with this in mind.

[wjk]

I have just submitted a PR, #622, that addresses these concerns.

[dotMorten]

EVERY single time I start a new project I delete the content and replace with a Grid, then get a compile error because I forgot to delete the click handler.
I just can't think of a good app layout where the root element would be a stack panel

[wjk]

The IDE1006 naming violation is derived from Visual Studio's automatic event-handler creation code. The x:Name is used as-is, along with the name of the event, to form the hander method name. This button has a name that starts with a lowercase letter, so that what is used. There is no reason why you cannot rename the function to start with a capital letter (Change All References will also catch the use in the XAML file in my experience), or why you cannot use x:Name identifiers that start with a capital letter.

[mrlacey]

It's not "automatic event-handler creation code" though, it's coming from the templates.

I appreciate that it (or pretty much anything) can be changed but I brought it up because having generated code that violates conventions and causes a warning to be displayed suggests there's something wrong with the generated code. Either that or there are different parts of Microsoft with different opinions that are being fought in the compiler warnings.
I also get that the x:Name has a convention to start with a lowercase character because it becomes a field in the generated code and the defacto standard for naming fields is to start with a lowercase letter.
I'd like to understand the decision that it was more important to reflect the casing of the name in the method than to follow the conventions for naming methods.
I too can come up with reasons for why things may be as they are but the purpose of opening this question was to get feedback from the people who made those decisions, not open speculation.

[mrlacey]

For transparency and tracking purposes of these questions, it seems the VSIX templates for WinUI3/Project Reunion may be moving to be part of Windows Template Studio: microsoft/TemplateStudio#4164