Support for an element extension mechanism

[Liander]

One use-case for having an extension mechanism on existing elements is already given here: https://github.com/aspnet/Blazor/issues/404#issuecomment-413037767, which can be used for form validation and the like. I didn't get any response on that so I will provide a little more extensive description this time to see if there is some interest. This time will be about providing a typed manner for Bootstrap concepts.
Let say we want to write:

 <ul Type="ListGroup">
    <li Active>First item</li>
    <li>Second item</li>
    <li>Third item</li>
 </ul>

instead of:

 <ul class="list-group">
    <li class="list-group-item active">First item</li>
    <li class="list-group-item">Second item</li>
    <li class="list-group-item">Third item</li>
 </ul>

and this:

<nav Type="Navbar" Expand="S" Color.Background="Dark" NavbarDark>
   <a Brand href="#">Logo</a>
   <ul>
      <li><a href="#">Link 1</a></li>
      <li><a href="#">Link 2</a></li>
      <li><a href="#">Link 3</a></li>
   </ul>
</nav>

instead of:

<nav class="navbar navbar-expand-sm bg-dark navbar-dark">
  <a class="navbar-brand" href="#">Logo</a>
  <ul class="navbar-nav">
    <li class="nav-item">
      <a class="nav-link" href="#">Link 1</a>
    </li>
    <li class="nav-item">
      <a class="nav-link" href="#">Link 2</a>
    </li>
    <li class="nav-item">
      <a class="nav-link" href="#">Link 3</a>
    </li>
  </ul>
</nav>

and get those extended attributes, Type, Expand, Color, etc. in a typed manner!

To describe how that can be accomplished I am getting into muddy waters… so take it with a grain of salt… but I am imagining a way to specify those extensions similar to this

[ElementExtension(AttributeName = "Type", TargetElements = "ul, div")]
public class ListType : ISingleValueProperty
{
   [Parameter]
   [StringLiteralConversion] 
   ListGroupValue Value { get; set; }

   void OnContentBegin(builder, renderSettings);  // Extends class attribute during render
}

[ElementExtension(AttributeName = "Colors", ExcludeType = ElementType.VoidElement)]
public class Colors : IMultipleValueProperty
{
   [Parameter]
   [StringLiteralConversion] 
   ContextualTextColor Text { get; set; }

   [Parameter]
   [StringLiteralConversion] 
   ContextualBackgroundColor Background { get; set; }

   void OnContentBegin(builder, renderSettings);  // Extends class attribute during render
}  

//...

1. Render extension hooks:
   Now we get into even muddier waters to talk about hooks into the render-builder… but see it as something to spur your thinking. I think it will be easiest to have a combination of run-time-calls and design-time-services, like having the calls

Action<Builder, ExtensionRenderSettings> OnAddArgument;
Action<Builder, ExtensionRenderSettings> OnContentBegin;
Action<Builder, ExtensionRenderSettings> OnContentEnd;

which are present in the cases when a design-time service returns them

bool TryGetOnAddArgument(parsed-argument-nodes??, 
    out Action<Builder, ExtensionRenderSettings> onAddArgument, 
    out ExtensionRenderSettings renderSettings)

But I am open to any suggestions. In addition, I expect there will be a need to resolve parameters at design-time also, thus the conversion attributes and in this case from string literals to replace their typed counterpart in the generated c# file.

2. Parameter tags:
   Somewhat semi-related is that I think it would make sense to allow these extended attributes to be set as tags also. Especially when it comes to multi-value settings of columns in a grid, etc., but I haven’t explored that. It relates somewhat also to this comment Add Support for Templated Components blazor#1404 (comment).

3. Parameter tag constructs:
   Having same construct of tags referring to a mix of types and parameters can get it even more convoluted then. Do you think it will make sense do introduce an attribute at module level to configure it, so that one can try different styles before it is settled?

[PropertyPrefix(PrefixType: ParentComponentName)]   // As in <MyPage.Header />
[PropertyPrefix("@Parent.", PrefixType: Fixed)]     // As in <@Parent.Header />
[PropertyPrefix("_.", PrefixType: Fixed)]           // As in <_.Header />, fixed placeholder for parent.

@SteveSandersonMS I mentioned point 2 and 3 here just so you can reflect on it with respect to this idea also.

I think this mechanism would be very powerful, although I must admit I am new to both Blazor and Bootstrap. I have a third use-case that could use this extension mechanism for another time.

Is this of any interest? Any thoughts?

[SteveSandersonMS]

Thanks for the suggestions, @Liander. We'll need to see what other scenarios emerge over time that might tie in with this sort of thing.

In general Blazor doesn't focus massively on the actual HTML representation aspect of the UI (e.g., giving shorthand names to attributes and CSS classes via macros), since that's not usually hugely difficult for the developer anyway. Blazor more focuses on the challenges of defining encapsulated components with their own logic and state, composing them, and responding to events.

We can definitely keep this on the backlog to see what usages might get attached to it and whether the value would be high enough to take the cost of extra syntax to understand and being less explicit about what DOM content ultimately gets built. Hope that's OK!

[RichiCoder1]

Late, but this would be great for something like https://chanan.github.io/Blazorous/
Currently it implements by using it's own Dynamic component, but it'd be great to be able to implement it as a property instead.

[mkArtakMSFT]

Hi. Thanks for contacting us.
We're closing this issue as there was not much community interest in this ask for quite a while now.
You can learn more about our triage process and how we handle issues by reading our Triage Process writeup.