Feature request: strongly-typed route values in `a` tag-helpers

[dharmatech]

The Issue

The example project from the Razor Pages with Entity Framework Core in ASP.NET Core - Tutorial includes the following code:

<a asp-page="./Index"
   asp-route-sortOrder="@Model.CurrentSort"
   asp-route-pageIndex="@(Model.Students.PageIndex + 1)"
   asp-route-currentFilter="@Model.CurrentFilter"
   class="btn btn-primary @nextDisabled">
    Next
</a>

Link to those lines in the project.

The route parameter names:

asp-route-sortOrder="@Model.CurrentSort"
asp-route-pageIndex="@(Model.Students.PageIndex + 1)"
asp-route-currentFilter="@Model.CurrentFilter"

are not strongly-typed. I.e. there could be a typo in any of the names (sortOrder, pageIndex, currentFilter) and the project will compile and run however the program will not function as expected.

Workaround - use LinkGenerator.GetPathByAction

This stackoverflow post discusses one workaround for the issue. The example there has the following a tag-helper:

    <a class="btn btn-block
       @(category == ViewBag.SelectedCategory 
           ? "btn-primary": "btn-outline-secondary")"
       asp-action="Index" asp-controller="Home"
       asp-route-category="@category"
       asp-route-productPage="1">
        @category
    </a>

It is rewritten in a more strongly-typed manner using LinkGenerator.GetPathByAction as follows:

<a class="btn btn-block @(category == ViewBag.SelectedCategory ? "btn-primary" : "btn-outline-secondary")"
   href="@(
    _linkGenerator.GetPathByAction(
        nameof(HomeController.Index), 
        Regex.Replace(nameof(HomeController), "Controller$", String.Empty),
        new IndexParameters() 
        { 
            Category = category, 
            ProductPage = 1 
        }))">
    @category
</a>

This is more of a demonstration of what is theoretically possible in the form of a quick solution; it's not ideal for end users.

Workaround - R4MVC

Another approach is to use R4MVC.

Here's a video demonstrating R4MVC.

Downsides to R4MVC:

• Still in pre-release
• Not built-in to ASP.NET Core

Workaround - object for parameters

If we use a class to represent the parameters to OnGetAsync:

public class OnGetAsyncParameters
{
    public SortOrder? SortOrder { get; set; }
    public string CurrentFilter { get; set; }
    public string SearchString { get; set; }
    public int? PageIndex { get; set; }
}

then instead of:

<a asp-page="./Index"
   asp-route-sortOrder="@Model.CurrentSort"
   asp-route-pageIndex="@(Model.Students.PageIndex + 1)"
   asp-route-currentFilter="@Model.CurrentFilter"
   class="btn btn-primary @nextDisabled">
    Next
</a>

we can use asp-all-route-data and generate a dictionary from an instance of OnGetAsyncParameters:

<a asp-page="./Index"
   asp-all-route-data="to_dict(new OnGetAsyncParameters()
    {
        SortOrder = Model.CurrentSort,
        PageIndex = Model.Students.PageIndex + 1,
        CurrentFilter = Model.CurrentFilter
    })"
   class="btn btn-primary @nextDisabled">
    Next
</a>

Link

where to_dict is the following utility function:

Dictionary<string, string> to_dict(object obj)
{
    return obj
        .GetType()
        .GetProperties(System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.Public)
        .ToDictionary(
            prop => prop.Name,
            prop =>
            {
                var val = prop.GetValue(obj, null);

                return val == null ? "" : val.ToString();
            });
}

In this case, OnGetAsync is updated to accept OnGetAsyncParameters:

public async Task OnGetAsync(OnGetAsyncParameters onGetAsyncParameters)

Link

Request

The request is for ASP.NET Core to have route parameters be more strongly-typed in a tag-helpers.

I understand that the priority may be low. I'd just like to request that it at least be on the roadmap. :-)

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[MichalSznajder]

Tag helpers are great but refactoring them is always a pain. Maybe source generators could be used here?

[dharmatech]

@MichalSznajder

Interestingly, this post from the .NET Blog:

Introducing C# Source Generators

suggests exactly that:

Another capability Source Generators can offer is obviating the use of some “stringly-typed” APIs, such as how ASP.NET Core routing between controllers and razor pages work. With a Source Generator, routing can be strongly typed with the necessary strings being generated as a compile-time detail. This would reduce the amount of times a mistyped string literal leads to a request not hitting the correct controller.

[dharmatech]

@MichalSznajder,

Tag helpers are great but refactoring them is always a pain.

(I'll get off topic here a bit.)

Yup, this is true. As opposed to Razor syntax, I prefer systems like JSX which look like markup but actually expand into regular JavaScript code. I wish we had something like this in ASP.NET Core. Something like JSX (csx?) which simply expands into C#. This way the page description code is fully in C# and thus you have the full power of the language to perform whatever refactoring you'd like.

For this reason, I like:

https://github.com/giraffe-fsharp/Giraffe

You write your page code in straight F#. So very powerful refactoring. However, it's not as mature as ASP.NET Core. E.g. nothing like tag-helpers there.

[dharmatech]

As an aside, I've been exploring an approach to getting views that are fully type-safe by having everything expressed in C# instead of Razor syntax. Video I recorded demonstrating this approach:

https://youtu.be/PIfX-u27TLY

[MichalSznajder]

I think this approach goes a little bit too far for me. I am into type-safe tag helpers not complete overhaul of whole Razor.

Maybe first step would be some extension of IHtmlHelper? Tag helpers use internally IHtmlHelper.

[dharmatech]

@MichalSznajder,

I think this approach goes a little bit too far for me. I am into type-safe tag helpers not complete overhaul of whole Razor.

Oh, I completely understand that such a radical approach may not be feasible for some folks. :-) Was just showing an approach I've been exploring to work around the lack of type-safety.