This is great news, thank you! Any idea when it will be released?

Thank you team for this feature.

Any time frame about when this feature will be on EAP?

So there are a few points I want to bring up. But first I want you to understand that I respect you folks and the work that you're doing. I've been following this stuff since the very beginning, as I was a very early Kendo customer and former Kendo Developer Champion and Certified Expert.

1) I've spent hundreds of hours with Telerik controls, and had to build dozens of workarounds for features that were not very well thought out or partially implemented. You folks could get away with that when the controls were Javascript, and you could just overwrite buggy methods with better functionality. That's not an option here, so the team needs to think differently.

2) Radzen was started by one of the original Kendo UI devs. He was able to figure this problem out, and his team is really small. So it's hard to take the "it's complicated" reasons very seriously. It's not a Blazor Core bug that no one can work around, other people have figured it out... they just built it the right way from the beginning. So your customers aren't going to really want to hear excuses. 

3) Part of the problem is that you folks are doing the same thing you've been doing for a decade, which is the "mile-wide, inch deep" principle of component development. You've got all these controls, and they all only do a small fraction of what people actually need. Like, why the heck did you folks build a Button control? Or a Textbox? These things have HTML5 equivalents, that's wasted engineering time. You folks have a Grid control that has LOTS of functionality, but can only handle the most basic of data structures.

And because you went mile wide, now you have to rewrite a bunch of the internals because the team didn't think you'd want to build tables with complex relationships. But WAIT! There's a TabStrip! Never mind you can already do that in Bootstrap or Foundation or any of the other layout frameworks you're likely to be using.

I'm being a little sarcastic to make a point. You folks make the best Blazor controls out there, bar none. And yet, right now I'm using a free competitor from one of your original employees. Because your Grid control has every feature you can possibly want... except for one of the most basic features it actually needs. So as one of your early beta testers, I had to rip Telerik.Blazor out of my projects... and six months later, the problem is still not fixed.

Don't make excuses. No one wants to hear how hard your job is, we're all developers with hard jobs. Just figure it out, and tell us when we can expect it to be done. And understand, the more unnecessary controls you build before that happens, the slower your adoption will be (and the less money the Blazor tools will make).

Just my $0.02.

System.Linq.Dynamic.Core comes from this repo: https://github.com/StefH/System.Linq.Dynamic.Core. So if you don't want to take the dependency, then pull the required code into the Telerik.Blazor assembly.

Either way, you should consider bumping up the priority on this. I helped roll out the Kendo Grid for Florida government .NET apps, and they now have over a dozen apps using it. They are considering moving to Blazor, but they would not even think about it if this issue remains unfixed.

Telerik Employees: This is actually super-easy to implement. Radzen's Blazor components support it using the System.Linq.Dynamic.Core NuGet package. It's relatively straightforward to turn a string into a navigatable lambda. 

You can also guarantee type safety by using lambdas for deep property navigation, like this:

        <TelerikGridColumn TItem="CompanyEmployee" Property="@(NameOf.Full<CompanyEmployee>(c => c.Team.DisplayName))" Title="Team Name" Width="200px">

Since I'm nice, I'll even give you the source code for the NameOf function, so that you can implement this in the product:

using System;

using System.Linq.Expressions;

namespace Telerik.Blazor
{

    /// <summary>
    /// Fills a gap in <see langword="nameof" /> by allowing you to use deep name references instead of local name references.
    /// </summary>
    /// <remarks>
    /// Solution modified from <see href="https://stackoverflow.com/a/58190566/403765" />.
    /// </remarks>
    [System.Diagnostics.CodeAnalysis.SuppressMessage("Design", "CA1000:Do not declare static members on generic types", Justification = "<Pending>")]
    public static class NameOf
    {
        #region Public Methods

        /// <summary>
        /// 
        /// </summary>
        /// <typeparam name="TSource"></typeparam>
        /// <param name="expression"></param>
        /// <returns></returns>
        public static string Full<TSource>(Expression<Func<TSource, object>> expression)
        {
            Ensure.ArgumentNotNull(expression, nameof(expression));

            var memberExpression = expression.Body as MemberExpression;
            if (memberExpression == null)
            {
                if (expression.Body is UnaryExpression unaryExpression && unaryExpression.NodeType == ExpressionType.Convert)
                    memberExpression = unaryExpression.Operand as MemberExpression;
            }

            var result = memberExpression.ToString();
            result = result.Substring(result.IndexOf('.') + 1);

            return result;
        }


        /// <summary>
        /// Allows you to create a source name expression when you need to have a prefixing variable in the result.
        /// </summary>
        /// <typeparam name="TSource"></typeparam>
        /// <param name="sourceFieldName"></param>
        /// <param name="expression"></param>
        /// <returns></returns>
        public static string Full<TSource>(string sourceFieldName, Expression<Func<TSource, object>> expression)
        {
            var result = Full(expression);
            result = string.IsNullOrEmpty(sourceFieldName) ? result : sourceFieldName + "." + result;
            return result;
        }

        #endregion
    }

}

Hope that helps implement the feature... it's a dealbreaker for pretty much anyone without it.

I am working with GIS data from an API, and by its nature it is complex.  Here is a simplified version of the JSON POCO I serialize to:

public class Address {
   public string StreetNumber;
   public string StreetName;
   public string FreeFormAddress;
}

public class Poi {
  public string Name;
  public string Category;
}

public class Result {
  public Address Address;
  public Poi Poi;
}

public class GIS {
  public Summary Summary;
  public IList<Results> Results
}

I get the json back, serialize it into the object, and then I want to display GIS.Results[x].Poi.Name, GIS.Results[x].Poi.Category, and GIS.Results[x].Address.FreeFormAddress in a Grid.  The nameof() does not produce qualified names, just the last property (Name, Category, and FreeFormAddress).  This is a limitation of nameof(), not Telerik.  Other Competitor products have the same issue.  

Issue 1 is the nested (complex) objects.  Issue 2 is the Ilist array within.  My question is the following solution the best approach?

For #1, the nameof() issue, I added Getters into Results to flatten the object:

public class Results {
   ....
   public string Name { get { return Poi.Name; } }
   public string Category { get { return Poi.Categories; } }
   public  string FreeformAddress { get { return Address.FreeformAddress; } }
}

For #2,

   public Ilist<Results> DataSource; 

Then 

    protected override void OnParametersSet()
    {
        base.OnParametersSet();
        if (GIS!= null)
        {
            DataSource = GIS.Results;
        }
    }

And then I set the grid as

            <TelerikGrid Data="DataSource"
                             SelectionMode="GridSelectionMode.Single"
                             @bind-SelectedItems="SelectedItems">
                <GridColumns>
                    <GridColumn Field="@nameof(Results.Name)" />
                    <GridColumn Field="@nameof(Results.Category)" />
                    <GridColumn Field="@nameof(Results.FreeformAddress)" />

                </GridColumns>
                </TelerikGrid>

It works, works fine, especially for a small set of columns.  But is this the best way?  Is there anything I'm missing?

This feature is literally a show stopper for me at this point.

I find this disappointing as it runs counter to the notion that the Telerik components offer a way of speeding up development. My requirement is only to display the results in the same way that is achieved with a HTML grid only faster.