Getting the webpage URL in VisibilityCondition Evaluate method

The response from the Kentico AI in the docs is correct, but there's also some nuance.

Task.GetAwaiter().GetResult() is the best way to "block" on asynchronous work, but it's still not great. It potentially uses another thread to do work which would have only required 1 thread. It can cause deadlocks but only in frameworks where there's a synchronization context.

There is no synchronization context in traditional ASP.NET Core MVC.

There is a synchronization context in ASP.NET Core Blazor.

So, as long as you are using .GetAwaiter().GetResult() in code that is not executed where there is a synchronization context then the code will work and you won't experience a deadlock. This can be difficult for libraries to ensure, but you know how your application code is used so you can avoid this pitfall.

If you look at the Kentico Community Portal you can see that I use .GetAwaiter().GetResult() in a personalization condition type because the Evaluate method is synchronous.

public override bool Evaluate()
{
    var context = contextAccessor.HttpContext;
    if (context is null)
    {
        return false;
    }

    var identity = context.User.Identity;

    if (identity is null || !identity.IsAuthenticated)
    {
        return false;
    }
    var id = identity as ClaimsIdentity;

    var member = userManager
        .GetUserAsync(context.User)
        .GetAwaiter()
        .GetResult();

    if (member is null)
    {
        return false;
    }

    var assignedMemberBadgeNames = badgeService
        .GetSelectedBadgesFor(member.Id)
        .GetAwaiter()
        .GetResult()
        .Select(b => b.MemberBadgeCodeName);

    return SelectedMemberBadges
        .IntersectBy(
          assignedMemberBadgeNames, 
          selected => selected.ObjectCodeName, StringComparer.OrdinalIgnoreCase)
        .Any();
}

Xperience APIs are gradually being made async (most already are) so you should need to use this workaround less and less over time.

Our APIs that work with Blazor (currently, only the Email Builder) are all async or have an async variant.

Your code should generally be async-first because ASP.NET Core is designed to be async (concurrent, not parallel) from top to bottom.

Thanks Sean. Is there any other way that I might get the PageUrl? Can I modify template properties from within the controller? Or add a value to a variable within the properties model from the controller? I would prefer to avoid using Task.GetAwaiter().GetResult() at all in the codebase because from my experience, async methodologies are still not well understood and other devs will see it and use it in places where they shouldn't or its not needed. On a few occasions, CoPilot recommended using Task.GetAwaiter().GetResult() in places where it wasn't needed. I am trying to set a good foundation/example in the code.

Thanks Sean. Unfortunately even if I use IWebPageDataContextRetriever  and then get the URL, like you said, it doesnt have the page context so there is no way to figure out which page I am on to determine if I should hide a property or not

Ah, yeah. I hadn't checked those APIs to see if they actually have access to that context, but that makes sense. The UI Form Components and related technology are not designed to have knowledge of the page they are used on, primarily because they can be used in other areas of Xperience's Admin UI, not just the Page Builder.

Slightly related, you can send the page context on a POST from your page's view by including the page data in your HTML form on the page. But, similar to what I mentioned above, this would be POSTing to your endpoint, not one of Xperience's.

Trevor helped me find the way with IHttpContextAccessor, which has the pageid hidden in the request path!!

contextAccessor.HttpContext!.Request.Form["path"].ToString().Split("/")[1].Split("_")[1];