Template based components

[danroth27]

For example, you should be able to create a Grid or ListView component that binds to each item in a collection using a define template.

[SteveSandersonMS]

Specifically, this means we need some way to signal that a given part of the child content within a component should get compiled as an Action<RenderTreeBuilder, T>, for some type T that we need to be able to resolve dynamically from usage at design time. Then our design-time codegen will be able to produce the correct intellisense context when writing Razor expressions inside that child element.

Example:

<MyListWithHeader RowItems=@People>
    <Title>
        Here I'm still in the outer context so can reference properties on the component itself 
        such as @TitleText
    </Title>
    <RowTemplate> <!-- Somehow need intellisense to know that RowTemplate is meaningful here, and that its "item" value is taken from the generic type arg on the RowItems property -->
        Here I'm in the context of an Action<RenderTreeBuilder, Person> because we supplied
        an IEnumerable<Person> as the value for RowItems, so I can write @item.FirstName
    </RowTemplate>
</MyListWithHeader>

@functions
{
    string TitleText { get; set; }
    IEnumerable<Person> People { get; set; }

    class Person
    {
        public string FirstName { get; set; }
    }
}

I'm not sure how general we want to make this feature. Possibly less general than indicated in the sketch above. @rynowak would be the expert on what's reasonable to implement here. All the complexity is at design/compile time. It doesn't require any runtime support that I can think of.

[abatista667]

Hi tried to accomplish this by my own passing an IEnumerable as a parameter, I was able to produce a grid but i was not able to update it when the parameter change. This is the code:

<table class="@ClassName">
  <tr>
    @foreach (var col in Columns)
    {
      <th>@col</th>
    }
  </tr>

  @foreach (System.Data.DataRow row in table.Rows)
  {
    <tr>
      @foreach (var col in Columns)
      {
        <td>@row[col]</td>
      }
      @if (Select != null)
      {
        <td><a @onclick(() => Select(row))>Seleccionar</a></td>
      }
    </tr>
  }
</table>

@functions{
    public string ClassName { get; set; }
    public List<string> Columns { get; set; }
    public object DataSource { get; set; }
    private System.Data.DataTable table;


    private string Log;

    //call backs it seens I will have many of them

    public Action Change { get; set; }
    public Action<object> Select { get; set; }

    protected void UpdateState()
    {
      int count = ((IEnumerable<object>)DataSource).Count();
      Log = $"Table count rows:{table.Rows.Count} count object ${count}";
      StateHasChanged();
    }

    protected override void OnInit()
    {
      base.OnInit();

      Change += StateHasChanged;

      var enumerable = (IEnumerable<object>)DataSource;
      table = new System.Data.DataTable();

      if (Columns == null)
      {
        Columns = new List<string>();
        Columns.AddRange(enumerable.FirstOrDefault().GetType().GetProperties().Select(x => x.Name).ToList());
      }


      Columns.ForEach(x =>
      {
        table.Columns.Add(x);
      });

      enumerable.ToList()
                .ForEach(x =>
                {
                  var row = table.NewRow();

                  foreach (var property in x.GetType().GetProperties())
                  {
                    row[property.Name] = property.GetValue(x);
                  }

                  table.Rows.Add(row);
                });

      StateHasChanged();
    }
}

[SvenEV]

@SteveSandersonMS, are Title and RowTemplate in your example meant to be properties of MyListWithHeader or special components? If they are properties, it might be worth thinking about alternative ways to express this...

I am working with XAML a lot and when I started prototyping with Blazor I quickly felt the need for this feature. Do you think XAML's property element syntax could be reasonable in this scenario? While quite verbose, it expresses clearly that we are assigning properties here instead of adding child components to MyListWithHeader. Example:

<MyListWithHeader>
    <MyListWithHeader.Title>
       ...
    </MyListWithHeader.Title>
    <MyListWithHeader.RowTemplate>
       ...
    </MyListWithHeader.RowTemplate>
</MyListWithHeader>

[DamianEdwards]

My personal view is that Razor should stick as close as possible to HTML idioms, rather than drifting towards the idioms we see in XAML. That would mean looking more like the hierarchy of elements you see in <table> rather than typical XAML things. We could be generic enough to support either mind you, but I'm still very firmly in the camp of "Razor is HTML" right now.

[touseefbsb]

totally in support of this. if we can make the list of item "ObservableCollection" rather than a "IEnumerable" that would be a bonus. moving towards xaml like pattrens gives us a proper template system, which html lacks, all of popular frameworks in web ui have a template system, which makes them very extensible, obviously blazor should have one as well, and instead of making a new one it would be great to have one which is already loved by MS and many .Net devs as well, technically it will still be html/css based so all html developers will still be attracted towards the technology because it wont be xaml ( dont knw why html guyx hate xaml though ) but it will only follow xaml pattrens.

[SvenEV]

@DamianEdwards I fully agree with you regarding "Razor is HTML". However, attribute values in HTML are always specified as, well, attributes in the opening tag. There is no way to (and no need to) express complex attribute values like templates as child elements. For example you can't write

<a>
    <href>http://dot.net</href>
</a>

So I think what we are aiming for technically just cannot be expressed in pure HTML.
Here's a summary of the options I currently see:

1. Stick with HTML syntax: Property values can only be specified in the opening tag of a component.

   • I think that is what React opted for, example:
     <MyListWithHeader RowTemplate={(data) => <p>...</p>} />
   • Pro: Very close to normal HTML syntax
   • Con: Gets messy for multiline values, i.e. more complex templates

2. Stick with HTML syntax: Depending on the context, child nodes of a component may either represent nested elements or property assignments.

   • Pro: Very close to normal HTML syntax
   • Con: Might be confusing since property assignments and child elements are syntactically indistinguishable. In the example, <Title>...</Title> might be a standalone component while <RowTemplate>...</RowTemplate> might be a property (an attribute) of the surrounding <MyListWithHeader> - without IntelliSense you don't really know
   • Con: Might cause naming conflicts if there's a component and a property with the same name

3. Invent new syntax: XAML's property element syntax is just one option, it could just as well be some Razor construct similar to @functions { } or something totally different.

   • Pro: Allows arbitrarily complex templates while still being readable
   • Con: Might alienate web devs

It is totally possible that I am misunderstanding something here. If so, please let me know.

[touseefbsb]

@SvenEV I dont think xaml syntax will alianate anyone, if u notice, the template syntax for angular, vue, react and million other frameworks, all have different way and different syntax to do stuff, still all of them are loved, NO? similarly blazor can have its own syntax, the only pro in its case will be we wont be inventing a new syntax just bringing over already popular syntax to this framework ( hence less learning curve for xaml devs ) but as far as web devs are concered they will be learning blazor templates anyway whether blazor follow xaml or not, learning curve for web devs remain the same, the only way web devs stay away from this drawback is if blazor uses straight up html, which I dont think will be as extensible as a template model. :)

[touseefbsb]

so a totally new template syntax gives learning curve to every developer. but a xaml like syntax solves atleast problem of half developers. but xaml is also a lot like html, both are markup afterall. once u learn it, it will be piece of cake, good thing abt xaml way is, u dnt have to worry abt css at all, all styling is done with straight up properties on the controls. and even comples styling also done with same syntax, but on the other hand html and css are totally different languages with different syntax and structure of doing things.

[MihaMarkic]

But why do we even need templates? I mean when you can do foreach right there in Razor. Seems much easier to me than templating.
Or is this because of reuse? I can imagine a separate component that does foreach in that case.

[touseefbsb]

@MihaMarkic templates standardize everything, it increases re-use, and most importantly it hides away all the complex code written for one control and u can just use that wrap control with 2 lines of code and focus more on ur business logic instead of re inventing the wheel.

[MihaMarkic]

Well, I don't know about this. IMO foreach is a template, just a more powerful one and you can place a "foreach" template in a different component and call it from anywhere with those two lines of code.

[touseefbsb]

foreach is just a loop and yes for a simpler control we can do this, like for a basic ListView ( table ) we can simply make a control which takes some input, does the foreachon it and spits out a table, and then we just need to put one tag <CustomTable Input=@"ListData"/> something like this and then we will be able to produce a table, also if we want a customized listview , with very modern design, highly interactive etc, then we can make another component control with foreach, and a lot of cutom css, and lot of blazor code in one file, maybe multiple files, and wrap all of that in 1 component, and then again use all of that just with 1 tag. you see where I am getting with this? no matter how much code a control has, all of that can be wrapped into 1 tag :) @MihaMarkic

[SvenEV]

It's not just about rendering multiple items with the same template. It's also needed to make multiple parts of a component customizable. Currently, a component can only have one such "hole" in its layout that can be filled with ChildContent, a predefined property, like this:

<div style="some fancy styling">
    @ChildContent
</div>

Now imagine you want to write a component with multiple such "holes" like a dialog that lets you customize the content as well as the header, or a button where you can customize the inner content but also specify templates for the context menu and the tooltip maybe. So it would be nice if you could write something like the following (whatever the syntax will be then):

<MyButton>
    <h2>I am the button caption (the usual ChildContent)</h2>

    <MyButton.ContextMenu>
        <button>Context menu button 1</button>
        <button>Context menu button 2</button>
    </MyButton.ContextMenu>
	
    <MyButton.ToolTip>
        This explains <strong>what the button does</strong>. It is displayed when hovering over the button.
    </MyButton.ToolTip>
</MyButton>

[MihaMarkic]

@SvenEV Isn't that just having multiple holes and not strictly requiring a template?

[touseefbsb]

yes tht is good example of another usecase, every part should be customizeable.