Enable Grid to dynamically switch layouts

[nandin-borjigin]

Usecase

Imagine we want to show a list of items and each list item is a 3-column grid.

+---+-------------+-------------------------------+
| 1 | Lorem Ipsum | Lorem ipsum dolor sit amet... |
+---+-------------+-------------------------------+

Now, we want to be responsive to the window size changes and decide to collapse this list item into 2 rows when the window width is narrow.

+-------+-----------------------+
|   1   |      Lorem Ipsum      |
+-------+-----------------------+
| Lorem ipsum dolor sit amet... |
+-------------------------------+

Potential approach

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="Auto"/>
    </Grid.RowDefinitions>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="Auto"/>
        <ColumnDefinition Width="Auto" x:Name="SecondColumn"/>
        <ColumnDefinition Width="*" x:Name="ThirdColumn"/>
    </Grid.ColumnDefinitions>
    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup>
            <VisualState x:Name="NarrowState">
                <VisualState.StateTriggers .../> <!-- Trigger implementation omitted -->
                <VisualState.Setters>
                    <Setter Target="Description.(Grid.Row)" Value="1"/>
                    <Setter Target="Description.(Grid.Column)" Value="0"/>
                    <Setter Target="Description.(Grid.ColumnSpan)" Value="2"/>
                    <Setter Target="SecondColumn.Width" Value="*"/>
                    <Setter Target="ThridColumn.Width" Value="0"/>
                </VisualState.Setters>
            </VisualState>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
    <TextBlock x:Name="Number">1</TextBlock>
    <TextBlock x:Name="Title">Lorem Ipsum</TextBlock>
    <TextBlock x:Name="Description">Lorem ipsum dolor sit amet...</TextBlock>
</Grid>

Problem

It's not really intuitive to declare a 2 x 3 grid layout when what we really need is either 1 x 3 or 2 x 2, depending on the window width. In above approach, we're imperatively dictating how the narrow layout would be instead of declaratively describing it and let the library handles the dirty work.
Further, another problem here is the visual state setter would quickly become maintenance hell when the layout becomes slightly complex. Just imagine what if we want to add column spacing to the grid.

Normal
+---+:+-------------+:+-------------------------------+
| 1 |:| Lorem Ipsum |:| Lorem ipsum dolor sit amet... |
+---+:+-------------+:+-------------------------------+

Narrow
+-----+:+-----------------------+:+
|  1  |:|     Lorem Ipsum       |:|
+-----+:+-----------------------+:+
| Lorem ipsum dolor sit amet... |:|
+-------------------------------+:+

This is what we would get if we simply add ColumnSpacing="10" on the Grid element. The gutter between 2nd and 3rd column is still there since the 3rd column is effectively there even if it's of 0 width, so the spacing exists. To better workaround this, we need to modify the visual state setters. We need to make the Title element span 2nd and 3rd columns and make the Description element span 3 columns. And this is only for a minor change like adding a column spacing.

Proposal

Provide Grid with a set of attached properties to enable programmers to declaratively describe the possible layouts and easily switch between them.

<Grid x:Name="RootGrid" GirdExentions.ActiveLayout="Normal">
    <!-- Declaratively define the possible layouts. -->
    <!-- GridExtensions.Layouts is a dictionary of GridLayoutDefinition -->
    <GridExtensions.Layouts>
        <GridLayoutDefinition x:Key="Normal">
            <!-- A GridLayoutDefinition consists of -->
            <!-- row definitions, column definitions and an area definition -->
            <GridLayoutDefinition.RowDefinitions>
                <RowDefinition Height="Auto"/>
            </GridLayoutDefinition.RowDefinitions>
            <GridLayoutDefinition.ColumnDefinitions>
                <ColumnDefinition Width="Auto"/>
                <ColumnDefinition Width="Auto"/>
                <ColumnDefinition Width="*"/>
            </GridLayoutDefinition.ColumnDefinitions>
            <!-- Area definition just simply puts down -->
            <!-- children names in desired order -->
            Number Title Description
        </GridLayoutDefinition>
        <GridLayoutDefinition x:Key="Narrow">
            <GridLayoutDefinition.RowDefinitions>
                <RowDefinition Height="Auto"/>
                <RowDefinition Height="Auto"/>
            </GridLayoutDefinition.RowDefinitions>
            <GridLayoutDefinition.ColumnDefinitions>
                <ColumnDefinition Width="Auto"/>
                <ColumnDefinition Width="*"/>
            </GridLayoutDefinition.ColumnDefinitions>
            Number      Title; <!-- semicolon is used to separate differnt rows -->
            Description Description <!-- row/column span is expressed by repeating the elment name -->
        </GridLayoutDefinition>
    </GridExtensionstensions.Layouts>
    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup>
            <VisualState x:Name="NarrowState">
                <VisualState.StateTriggers .../> <!-- Trigger implementation omitted -->
                <VisualState.Setters>
                    <!-- Only ActiveLayout property on the root grid needs to change according to the visual state -->
                    <Setter Target="RootGrid.(GridExtensions.ActiveLayout)" Value="Narrow">
                </VisualState.Setters>
            </VisualState>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
    <TextBlock x:Name="Number">1</TextBlock>
    <TextBlock x:Name="Title">Lorem Ipsum</TextBlock>
    <TextBlock x:Name="Description">Lorem ipsum dolor sit amet...</TextBlock>
</Grid>

[nandin-borjigin]

PR made here #4474

[michael-hawker]

Hi @nandin-borjigin, appreciate your enthusiasm for this topic. It'd be good to map out some different scenarios we'd like to address and possible alternatives for how we can accomplish these goals. Is extending Grid the best option or is this a new type of panel for instance?

Have you see this proposal in the WinUI repo? It covers some similar ideas as well, so it'd be interesting to compare and contrast those suggestions from the platform team with what you're trying to do here as well.

Mind if we talk about this a bit more and figure out how we can ensure we create a general solid solution to the issues you're trying to solve?

[mrlacey]

@michael-hawker Yes, I like your alternative better. However, I'm wondering how it holds up with large grids (containing lots of elements) or when there are lots of Visual States. It could end up with lots of duplication that means the same values are set for each element in different states.
Instead, what if a default layout was defined and then different states only specified the differences. So something like this:

<Grid x:Name="RootGrid" ui:GridExtensions.ActiveLayout="Default">
    <ui:GridExtensions.Layouts>
        <ui:DefaultGridLayoutDefinition Rows="Auto" Columns="Auto,Auto,*">
            <ui:GridLayoutData Target="{x:Bind Number}" Column="0" />
            <ui:GridLayoutData Target="{x:Bind Title}" Column="1" />
            <ui:GridLayoutData Target="{x:Bind Description}" Column="2" />
        </ui:DefaultGridLayoutDefinition>
        <ui:GridExtensions.Layouts.AlternateLayouts>
            <ui:GridLayoutDefinition x:Key="Medium" Rows="Auto,Auto" Columns="Auto,*">
                <ui:GridLayoutData Target="{x:Bind Description}" Row="1" ColumnSpan="2" />
            </ui:GridLayoutDefinition>
            <ui:GridLayoutDefinition x:Key="Narrow" Rows="Auto,Auto,Auto" Columns="*">
            <ui:GridLayoutData Target="{x:Bind Title}" Row="1" Column="0" />
                <ui:GridLayoutData Target="{x:Bind Description}" Row="2" Column="0" />
            </ui:GridLayoutDefinition>
        <ui:GridExtensions.Layouts.AlternateLayouts>
    </ui:GridExtensions.Layouts>

    <TextBlock x:Name="Number">1</TextBlock>
    <TextBlock x:Name="Title">Lorem Ipsum</TextBlock>
    <TextBlock x:Name="Description">Lorem ipsum dolor sit amet...</TextBlock>
</Grid>

To me, this feels closer to the current ways of working with a Grid and VisualStates but adding increased flexibility without a lot of extra syntax. As we're already looking at a complex scenario, it would be good to minimize the extra number of ways of doing things that developers need to know/learn/remember.
As a general guide: if the aim is to make it easier to work with the current Grid, it would be good to work with what's already there. If the aim is to completely reimagine how to work with "grids" then an entirely new control may be a better way to distinguish what functionality is available where and how best to work with different controls.

I'm aware that there is a possible performance issue with the way my "default layout" solution could be implemented. This shouldn't be an automatic reason to dismiss it though.

[michael-hawker]

Thanks @mrlacey! Yes, I was actually thinking of a default layout scenario as well, but forgot to articulate that point in my proposal.

(Using WinUI 3 syntax for brevity here.)

<Grid x:Name="RootGrid" RowDefinitions="Auto" ColumnDefinitions="Auto,Auto,*">
    <ui:GridExtensions.Layouts>
        <ui:GridLayoutDefinition x:Key="Normal" Rows="Auto" Columns="Auto,Auto,*">
            <ui:GridLayoutData Target="{x:Bind Number}" Column="0"/>
            <ui:GridLayoutData Target="{x:Bind Title}" Column="1"/>
            <ui:GridLayoutData Target="{x:Bind Description}" Column="2"/>
        </ui:GridLayoutDefinition>
        <ui:GridLayoutDefinition x:Key="Narrow" Rows="Auto,Auto" Columns="Auto,*">
            <ui:GridLayoutData Target="{x:Bind Number}" Row="0" Column="0"/>
            <ui:GridLayoutData Target="{x:Bind Title}" Row="0" Column="1"/>
            <ui:GridLayoutData Target="{x:Bind Description}" Row="1" ColumnSpan="2"/>
        </ui:GridLayoutDefinition>
    </ui:GridExtensions.Layouts>

    <TextBlock x:Name="Number" Grid.Column="0">1</TextBlock>
    <TextBlock x:Name="Title" Grid.Column="1">Lorem Ipsum</TextBlock>
    <TextBlock x:Name="Description" Grid.Column="2">Lorem ipsum dolor sit amet...</TextBlock>
</Grid>

Basically the idea is that you would define your Grid as normal with attached properties and the layout you want as the default as you would normally, and just not set the ActiveLayout property when you want to change it.

The ActiveLayout when changed just applies it's changes on top of the existing Grid. I guess the implementation detail here I didn't think about was that it'd need a way to remember what the previous value was to be able to reset back to the default in this case. It could also be tricky if you expected it to not set a property, you'd have to override it basically in each alternate layout.

So the advantage in your proposal would be the more clearly defined starting state that'd be easier to reset to afterwards as it's encapsulated. And in that case since we wouldn't want folks to define the locations in the Grid, it may be easier as a new control that contains encapsulates the Grid potentially vs. being a Grid, as you allude to,.. 🤔

[Arlodotexe]

Defining an element's grid placement as cleanly as possible.

This seems to be what solving this problem boils down to.

While the existing tooling works, it's very clunky since VisualState setters take up an entire row per property.

It can make maintaining, updating, or even just visualizing a simple Grid more difficult, especially when you've got more than a few Visual States.

Current platform approach

<VisualState.Setters>
    <Setter Target="ContentBlockA.(Grid.Column)" Value="0"></Setter>
    <Setter Target="ContentBlockB.(Grid.Column)" Value="0"></Setter>
    <Setter Target="ContentBlockC.(Grid.Column)" Value="0"></Setter>
    <Setter Target="ContentBlockA.(Grid.Row)" Value="2"></Setter>
    <Setter Target="ContentBlockB.(Grid.Row)" Value="1"></Setter>
    <Setter Target="ContentBlockC.(Grid.Row)" Value="0"></Setter>
    <Setter Target="ContentRowZero.Height" Value="Auto"></Setter>
    <Setter Target="ContentColumnZero.Width" Value="*"></Setter>
</VisualState.Setters>

I see two proposed approaches so far, and I think there's a case to make for both of them.

---

AreaDefinitions

Brings Row / Column definitions down to less than one line per element, since multiple elements are declared on each line.

The original proposal took inspiration from grid-template-areas to solve this problem, making the layout definition Declarative, rather than Imperative.

<Grid>
  <ui:GridLayoutDefinition>
    <ui:GridLayoutDefinition.AreaDefinition>
      ElementA ElementB ElementC;
      ElementA ElementD ElementD;
      ElementE ElementE ElementE
    </ui:GridLayoutDefinition.AreaDefinition>
  </ui:GridLayoutDefinition>
  <Border x:Name="ElementA"/>
  <Border x:Name="ElementB"/>
  <Border x:Name="ElementC"/>
  <Border x:Name="ElementD"/>
  <Border x:Name="ElementE"/>
</Grid>

Pros:

• Significantly reduces the complexity of declaring, visualizing, changing and maintaining simple grids.
• The easiest to understand visualize approach from a dev perspective, regardless of skill level.

Cons:

• Needs better syntax, that doesn't feel foreign to XAML devs.
• It has the same compile-time safety that a style setter would (that is, very little)
  • We can add compile-time safety for something like this using Source Generators if we absolutely must, which will take extra work.
• You cannot overlap grid areas with this approach.
  • Worked around by specifying grid columns and rows manually.

GridLayoutDefinition

Brings Row / Column definitions down to one line per element by defining Row and Column on the same line.

<Grid x:Name="RootGrid" RowDefinitions="Auto" ColumnDefinitions="Auto,Auto,*">
    <ui:GridExtensions.Layouts>
        <ui:GridLayoutDefinition x:Key="Narrow" Rows="Auto,Auto" Columns="Auto,*">
            <ui:GridLayoutData Target="{x:Bind Number}" Row="0" Column="0"/>
            <ui:GridLayoutData Target="{x:Bind Title}" Row="0" Column="1"/>
            <ui:GridLayoutData Target="{x:Bind Description}" Row="1" ColumnSpan="2"/>
        </ui:GridLayoutDefinition>
    </ui:GridExtensions.Layouts>

    <TextBlock x:Name="Number" Grid.Column="0">1</TextBlock>
    <TextBlock x:Name="Title" Grid.Column="1">Lorem Ipsum</TextBlock>
    <TextBlock x:Name="Description" Grid.Column="2">Lorem ipsum dolor sit amet...</TextBlock>
</Grid>

Pros:

• Compile time safety for free.
• Functionally just as flexible as the platform approach
• Much cleaner than the platform approach

Cons:

• Supplants the VisualState system entirely, which I'm not a big fan of. Instead, maybe:

<VisualState.Setters>
    <Setter Target="RootGrid.(ui:Layout)">
        <Setter.Value>
            <ui:GridLayoutDefinition Rows="Auto,*" Columns="Auto,Auto,*">
                  <ui:GridLayoutData Target="Title" Column="1" Row="0"/>
                  <ui:GridLayoutData Target="Description" Column="2" Row="2" />
            </ui:GridLayoutDefinition>
        </Setter.Value>
    </Setter>
</VisualState.Setters>

---

Overall, as long as they all have some kind of compile type safety and they play nicely with the VisualState system, I see solid use cases for both of these solutions, though the syntax definitely needs refining.

[michael-hawker]

Thanks for cleaning up the breakdown @Arlodotexe! Would be curious if we could somehow abstract this out into something we could query a larger pool of devs about... 🤔 Maybe we just 🦙-squad it on Discord?

I think the Con for the GridLayoutDefinition is that it's still not as easy to visualize the layout structure which is what the css-templates attempts to do. I don't see not having direct interface with the VisualState system as a con as not everyone wants to create a VisualState for all layouts or grid scenarios. You could also control the Layout property itself from the visual state still to swap between them or swap with a binding or a behavior instead if that works better. Imagine cases where the user can choose from a set of layouts vs. adaptive layouts using Visual States.

[XAML-Knight]

 <Grid>
   <ui:GridLayoutDefinition>
     <ui:GridLayoutDefinition.AreaDefinition>
       ElementA ElementB ElementC;
       ElementA ElementD ElementD;
       ElementE ElementE ElementE
     </ui:GridLayoutDefinition.AreaDefinition>
   </ui:GridLayoutDefinition>
   <Border x:Name="ElementA"/>
   <Border x:Name="ElementB"/>
   <Border x:Name="ElementC"/>
   <Border x:Name="ElementD"/>
   <Border x:Name="ElementE"/>
 </Grid>

I like this new approach to defining a layout, and while initially not knowing what I was seeing, I most importantly kept an open mind and appreciated someone finding a clever way around a XAML problem.

[mrlacey]

I'd like to strongly dispute this claimed pro for AreaDefinitions:

The easiest to understand approach from a dev perspective.

It's an entirely new approach and something not seen anywhere else in XAML, so claiming it's easy to understand without any broad level of feedback is optimistic at best. Imagine seeing this for the first time in a codebase that you inherit from someone else. My first thought is WTF. Even after thinking on this problem for a few days, I still see the example and think it looks weird and wrong and out of place inside a XAML file. I look at it and wonder about what it might mean and how it might be interpreted and don't have certainty.
Introducing a new way of representing the structure of the UI should only be done with great care, lots of external feedback, and verification that it doesn't have an impact on existing tooling.

Regarding the GridLayoutDefinition option, I'd like to see more examples of how it works with Visual State definitions so there is a complete example of what would be used in an implemented version.
I'd also like to clarify whether it's necessary to provide GridLayoutData for every named element inside the Grid. All the examples so far have done this but I feel it adds unnecessary duplication. Instead, I'd like to see it only be necessary to set a value to that which is different to the default value.
To try and make clearer what I mean, it would allow the removal of the following two lines from the above example.

<Grid x:Name="RootGrid" RowDefinitions="Auto" ColumnDefinitions="Auto,Auto,*">
    <ui:GridExtensions.Layouts>
        <ui:GridLayoutDefinition x:Key="Narrow" Rows="Auto,Auto" Columns="Auto,*">
-            <ui:GridLayoutData Target="{x:Bind Number}" Row="0" Column="0"/>
-            <ui:GridLayoutData Target="{x:Bind Title}" Row="0" Column="1"/>
            <ui:GridLayoutData Target="{x:Bind Description}" Row="1" ColumnSpan="2"/>
        </ui:GridLayoutDefinition>
    </ui:GridExtensions.Layouts>

    <TextBlock x:Name="Number" Grid.Column="0">1</TextBlock>
    <TextBlock x:Name="Title" Grid.Column="1">Lorem Ipsum</TextBlock>
    <TextBlock x:Name="Description" Grid.Column="2">Lorem ipsum dolor sit amet...</TextBlock>
</Grid>

They're not necessary as they set the same values for Grid.Row and Grid.Column as are already provided by default.

The consequence here is that it would make implementation more complicated when switching between different layouts as everything would need to be reset back to the default position within the grid if an element was changed in one layout but another layout didn't have a specific override for that element.
If we go down this route, more complex examples would (I believe) show the implication of this decision more clearly.

[XAML-Knight]

It's an entirely new approach and something not seen anywhere else in XAML

How about this, or am I angering the XAML Gods even further?:

    <Grid>
        <TextBlock FontSize="72">Text</TextBlock>
    </Grid>

[mrlacey]

Not sure if you're trying to be snarky or funny. 😕
What's new is using a combination of space and semicolon-delimited strings, which may or may not be over multiple lines to define a layout. Oh, and it uses x:Name in a new way, and those names may appear more than once.

It's like saying "Hey developers, you know how you've learned to look at an XML document and picture in your mind how that will translate to controls on a screen, well, here's something entirely new, that works differently, that you've got to learn and hold in your head too."

Or maybe I am overreacting and it is just "Text".

[Arlodotexe]

I'd like to strongly dispute this claimed pro for AreaDefinitions:

The easiest to understand approach from a dev perspective.

It's an entirely new approach and something not seen anywhere else in XAML, so claiming it's easy to understand without any broad level of feedback is optimistic at best. Imagine seeing this for the first time in a codebase that you inherit from someone else. My first thought is WTF. Even after thinking on this problem for a few days, I still see the example and think it looks weird and wrong and out of place inside a XAML file.
What's new is using a combination of space and semicolon-delimited strings, which may or may not be over multiple lines to define a layout

Maybe "easiest to understand approach" wasn't the right wording. "easiest to visualize" is a much more appropriate description, and it's important because it applies to developers of all skill levels.

I agree with the general sentiment. It may be readable, but the proposed syntax really needs improvement. It should feel more familiar to XAML devs, maybe something like:

<Grid>
    <ui:GridExtensions.AreaDefinitions>
        <ui:AreaDefinition>ElementA, ElementB, ElementC</ui:AreaDefintion>
        <ui:AreaDefinition>ElementA, ElementD, ElementD</ui:AreaDefintion>
    </ui:GridExtensions.AreaDefintions>
    
   <Border x:Name="ElementA"/>
   <Border x:Name="ElementB"/>
   <Border x:Name="ElementC"/>
   <Border x:Name="ElementD"/>
</Grid>

[dotMorten]

I think the scenario described above is totally valid. However I don't think (mis)using Grid to solve that scenario is the right avenue. IMHO it looks more to me like what you really need is a wide and narrow template to switch between. For instance the TwoPaneView control does exactly this for you.

[Arlodotexe]

We're discussing a new control that was designed independently by different community members and may serve some of the use cases covered by this idea -> #540