Support importing components with @using directives

[ajaybhargavb]

dotnet/aspnetcore#5577

• Modified ComponentTagHelperDescriptorProvider to allow component binding using short name as well as fully qualified name.
• Components don't respect add/removeTagHelper/tagHelperPrefix directives. Having those in component document will error.
• Regular Mvc views/pages don't support components.
• Moved namespace computation logic to TagHelperBindingPhase to support importing components that are already in scope.
• Added some design time code gen to keep using directives from graying out.
• Made the using directive parsing a little better.
• Suppressed legacy taghelper directive completion in component documents.

Future work:

• I didn't touch any of the tagHelperPrefix handling at this point because it only affects components when we support components in legacy views/pages.
• Respecting namespace directive (This isn't currently supported. Need to do Add support for @namespace directive for components aspnetcore#8007 before this).
• Respecting using alias.

[ajaybhargavb]

I noticed RazorParserOptionsBuilder already had a FileKind property but it wasn't being passed through to RazorParserOptions. I needed this info to suppress tag helper directive completion for component documents.

[rynowak]

😻

At least I had the idea that we should do this.

[NTaylorMullen]

Talked offline, FileKind shouldn't be part of the parser options since 1 project engine can parse both Components and Legacy Views. Implications of removing this means that we'll need to change the consumers to rely on the CodeDocument or other better per-file information to more accurately represent when a parse is operating on a Component document vs. a Legacy document. Parser options are technically configured per-parse but introduce issues when you need to fabricate parser options in a static environment without a file present (we do this in a few places).

[NTaylorMullen]

It's awesome to see it all come together. Looking shnazzzy!

[NTaylorMullen]

So it generates typeof(abcd<..........>) and ignores nested generics? Is that expected?

I know Components do something similar at runtime but I believe they use Roslyn to restringify their type name.

[ajaybhargavb]

There is no need to worry about nested generics. All we need to know is the count of generic type arguments.

Counter => typeof(Counter)
Counter<string, int> => typeof(Counter<,>)
Counter<string, string, int> => typeof(Counter<,,>)

[NTaylorMullen]

I see 👍

[rynowak]

Would it be crazy to just avoid using qualified names during design time?

So instead of builder.OpenComponent<MyApp.FooBar.Counter>() just generate builder.OpenComponent<Counter>().

One of the things we may need to do eventually is give a line-mapping to one of the statements we generate so that FAR can target it.

[ajaybhargavb]

So instead of builder.OpenComponent<MyApp.FooBar.Counter>() just generate builder.OpenComponent<Counter>()

But we don't generate any builder.OpenComponent<>() during design time (Except for type inference for generic components). Is this a bug?

Here is what gets generated for this input,

@using MvcWithComponents.Components

<Counter></Counter>

<Generic Item="17"></Generic> 

Generated design time code:

// <auto-generated/>
#pragma warning disable 1591
namespace MvcWithComponents
{
    #line hidden
    using TModel = global::System.Object;
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Threading.Tasks;
    using Microsoft.AspNetCore.Components;
#line 1 "C:\Users\ajbaaska\Source\Repos\MvcWithComponents\MvcWithComponents\TestComponent.razor"
using MvcWithComponents.Components;

#line default
#line hidden
    public class __TestComponent : Microsoft.AspNetCore.Components.ComponentBase
    {
        #pragma warning disable 219
        private void __RazorDirectiveTokenHelpers__() {
        }
        #pragma warning restore 219
        #pragma warning disable 0414
        private static System.Object __o = null;
        #pragma warning restore 0414
        #pragma warning disable 1998
        protected override void BuildRenderTree(Microsoft.AspNetCore.Components.RenderTree.RenderTreeBuilder builder)
        {
            base.BuildRenderTree(builder);
            builder.AddAttribute(-1, "ChildContent", (Microsoft.AspNetCore.Components.RenderFragment)((builder2) => {
            }
            ));
            __o = typeof(Counter);
            __Blazor.MvcWithComponents.__TestComponent.TypeInference.CreateGeneric_0(builder, -1, -1, 
#line 5 "C:\Users\ajbaaska\Source\Repos\MvcWithComponents\MvcWithComponents\TestComponent.razor"
               17

#line default
#line hidden
            );
            __o = typeof(Generic<>);
        }
        #pragma warning restore 1998
    }
}
namespace __Blazor.MvcWithComponents.__TestComponent
{
    #line hidden
    internal static class TypeInference
    {
        public static void CreateGeneric_0<TItem>(global::Microsoft.AspNetCore.Components.RenderTree.RenderTreeBuilder builder, int seq, int __seq0, TItem __arg0)
        {
        builder.OpenComponent<global::MvcWithComponents.Components.Generic<TItem>>(seq);
        builder.AddAttribute(__seq0, "Item", __arg0);
        builder.CloseComponent();
        }
    }
}
#pragma warning restore 1591

[ajaybhargavb]

@rynowak ping

[rynowak]

But we don't generate any builder.OpenComponent<>() during design time (Except for type inference for generic components). Is this a bug?

It would be a good thing to add I think. It's better than doing something artificial IMO.

[ajaybhargavb]

It would be a good thing to add I think. It's better than doing something artificial IMO.

I tried this but it gets sort of complicated because we need to do things differently when we do type inference vs when we don't. Generating just a typeof() in all cases seems cleaner and simpler.

[rynowak]

ok

[ajaybhargavb]

🆙 📅

[NTaylorMullen]

As an initial click stop the design LGTM. 👍

[ajaybhargavb]

As an initial click stop the design LGTM.

@NTaylorMullen, could you elaborate a little more? I plan to do whatever I listed in future work separately (It's okay to not support those in the first cut). So, is there anything design-wise you expect will change here?

[NTaylorMullen]

So, is there anything design-wise you expect will change here?

Nope.

[rynowak]

cool beans

[ajaybhargavb]

🆙 📅 Added a lot more tests.

[ajaybhargavb]

Had to add this. Without this some tests were breaking cross-plat.

[adrianwright109]

What about namespaces that contain a . - would it be worth added more InlineData to cover these scenarios?

E.g.

        [InlineData("SomeProject.SomeNamespace.Foo", true, "SomeProject.SomeNamespace", "Foo")]
        [InlineData("SomeProject.SomeNamespace.Foo<Bar>", true, "SomeProject.SomeNamespace", "Foo<Bar>")]
        [InlineData("SomeProject.SomeNamespace.Foo<Bar.Baz>", true, "SomeProject.SomeNamespace", "Foo<Bar.Baz>")]
        [InlineData("SomeProject.SomeNamespace.Foo<Bar.Baz>>", true, "", "SomeProject.SomeNamespace.Foo<Bar.Baz>>")]
        [InlineData("SomeProject.SomeNamespace..Foo<Bar>", true, "SomeProject.SomeNamespace.", "Foo<Bar>")]

[ajaybhargavb]

@adrianwright109, that probably won't add value as we stop and return whatever is left once we parse the type name.