Make ResourcesTagHelper extensible

[sarahelsaig]

Is your feature request related to a problem? Please describe.

Right now you can define any custom resource type in the resource manager and this is pretty cool. For example in Lombiq.VueJs we use it to define Vue SFC resources and JS module resources. But there is a huge pain point: the <resources /> tag helper doesn't support any other resource type besides the built-in ones, so if you add a custom resource type you can require it but it won't be rendered.

This leads to a lot of added complexity and additional failure points, because you have to display the resources in weird ways, such as using widgets, custom themes or by injecting the render into the Content zone (since other zones are not guaranteed to exist depending on the theme).

Describe the solution you'd like

To avoid the above mentioned complexity, I propose adding the following interface:

public interface IResourcesTagHelperProcessor
{
    Task ProcessAsync(ResourcesTagHelperProcessorContext context);
}

public record ResourcesTagHelperProcessorContext(
    TagHelperContext TagHelperContext,
    TagHelperOutput Output,
    ResourceType Type);

This would be invoked for each implementation at the end of ResourcesTagHelper.ProcessAsync. This way anyone can add a custom resource types and render logic without having to do workarounds and it will seamlessly work with all existing styles that use the <resources /> tag helper.

[hishamco]

Please show us an example of a custom resource in which the built-in APIs don't fit nicely

[sarahelsaig]

Earlier I've implemented JS module support for which I introduced script-module resource type. This resource type is different from the built-in script because modules can use the import JS keyword to reference other module files by name so they don't have to be bundled or all included in the calling HTML. This requires an import map that pairs the module names to their paths. So when requiring a script-module, their dependencies should go into a <script type="importmap"> instead (see import here and matching resource definition here). This is currently implemented using an MVC filter and it turns out that doesn't work in some scenarios and isn't very elegant anyway. Being able to amend this in the <resources /> tag helper would be much safer.

Note that I know it works because I've already implemented a simplified version of this in a client project using a dirty workaround. If you are interested, the trick is that I create a new class with the same [HtmlTargetElement("resources", Attributes = nameof(Type))] attribute that also contains the expanded logic, then include @addTagHelper *, MyClientProject.Theme in the theme's _ViewImports.cshtml file as the very first @addTagHelper entry. This overrides the built-in tag helper, but only works in custom themes and it's an unnecessary hassle. My proposed solution would work for the built-in themes as well and would not require special actions from the consuming code when developing a module.

[sebastienros]

Do you think we'll have to remove the ResourceType enum to use a string instead? The only drawback would be the loss of intellisense.

[sarahelsaig]

No, the ResourceType enum can stay. It's not actually related to the resource type I meant. I wish it was called something like ResourceTagType or ResourceRenderLocation instead, because the role it serves it's more similar to ResourceLocation than to ResourceDefinition.Type so the name is a bit confusing.