Hi Fabian,

The best way to know when updates happen is to click the Follow button on the page and the portal will send you emails with updates as they occur. We do keep the portal as up-to-date as possible and this page's status will also be updated when we work on a fix for this (the page would then also include the version number that will carry it).

Regards,
Marin Bratanov
Progress Telerik

Hi Philip,

Reducing the grid size helps and it is the best one I can offer. The next one is what I offered in my previous post - implementing a column chooser where people will set the size and order of the columns they want visible.

I have seen similar exception a couple of times and at this point they look a lot like performance issues in the framework - it simply can't catch up quickly enough between the C# and JS parts of the code. Whether it will be possible for us to somehow work around this will require a significant research, and it is not a given - the error is all in the framework, the stack trace does not indicate a place where we could plug to avoid it somehow.

That said, I have raised the priority of this issue so maybe we could get to investigating it in one of the next releases.

Regards,
Marin Bratanov
Progress Telerik

I can suggest a couple of things to improve the UX with those constraints:

• Implement a column chooser: https://feedback.telerik.com/blazor/1450105-column-chooser. This will let them pick ony certain columns and that way there may be more real estate for the current ones. You can now use a MultiSelect widget for that, by the way.
• Use a descriptor for the columns that also has a field for their Width so you can predefine some common requests. You can also edit those fields through the column chooser grid so your end users can have control over that and then even store the state they chose in a database (see here).

Regards,
Marin Bratanov
Progress Telerik

Hi René,

Yes, it will be there in 2.8.0, this is not about our performance but how the framework lags a little behind the UI in and disposal in such scenarios. It is a guess, but maybe the WASM flavor won't have this issue (but it is not production-ready yet). We will need to get to investigating this particular scenario and error to see if we can solve it, it is rather specific.

The virtual scrolling is unlikely to support grouping because grouping is recursive and changes dramatically the rendering, while virtualization features rely on steady rendering of the same items. You can find the other limitations of this feature in its docs: https://docs.telerik.com/blazor-ui/components/grid/virtual-scrolling#limitations. You may also find useful the Notes section above it. FIltering, works fine with virtualization, however, so that may be useful.

Regards,
Marin Bratanov
Progress Telerik

Hi René,

That's over 3000 DOM elements for the table, and at this size browser performance suffers, and with a second layer of DOM manipulation abstractions (Blazor) on top of it, things can get messy.

My best advice is to reduce the page size. This will help with general performance as well, not just this error.

I can reproduce the error with large grids (I could not with <20 rows by 30 columns), and I am logging this for research so we can see if there is anything we can do to avoid/suppress the error.

Regards,
Marin Bratanov
Progress Telerik

Hello,

I cannot reproduce an error with this and switching tabs (based on the previous grid with the 30 columns and 10 items per page:

<TelerikTabStrip>
    <TabStripTab Title="First">
        <GridWithSlowData />
    </TabStripTab>
    <TabStripTab Title="second">
        <GridWithSlowData />
    </TabStripTab>
</TelerikTabStrip>

The 2.8.0 release should be out by the end of day today (perhaps even within a couple of hours). Let's try this with 2.8.0 and see if it still manifests.

At this point I am thinking that this issue may be related to the missing proper unmounting hook in the framework (see https://github.com/dotnet/aspnetcore/issues/13026). We do use the Dispose method from IDisposable to call the .DisposeDotNetObjectRef(DotNetInstance); method of the JS interop we use, and to also call other JS code to clean up our objects, and it is up to the framework to handle that gracefully (we have it in a  if (DotNetInstance != null) block, so it should not throw). It looks like the framework has managed to dispose something in a wrong place/time, however, and throws, and I am not sure we can control that.

Regards,
Marin Bratanov
Progress Telerik

Hello René,

The window during a component initialization is so narrow that I am not sure how such a test can be achieved in general. For example, a WASM app would be "frozen" because all rendering and initialization happens in one thread (WASM in the browser does not do multithreading yet) so the next click should not register, on the server the performance and initialization should be faster. Moreover, with our upcoming 2.8.0 release, the grid performance will improve drastically, which should reduce this window.

In the meantime, I can suggest reducing the HTML footprint of the grid - usually reducing the number of rows helps. The sheer amount of HTML to render and maintain can slow down a browser - for example, 25 columns x 20 rows (without templates, templates will weigh things down more) will result in about 600 DOM elements for the cells and rows alone which does not consider any logic running behind them.

I tried my previous sample and approach by adding 30 columns like this (with and without the artificial Task.Delay() in the data loading):

        @foreach (var item in Enumerable.Range(1, 30))
        {
            <GridColumn Field=@nameof(SampleData.LastName) Title="Last Name" />
        }

But I did not manage to reproduce an error. How do you reproduce that? Do you click a different tab or a NavLink? You could send me a short video of your actual case in a private ticket (in order to keep any sensitive data on the screen from the general public) so I can see what to do in order to try to reproduce this.

Regards,
Marin Bratanov
Progress Telerik

Hello René,

Thank you for the update.

If you have any guidance on what I might be missing and what I can try to reproduce this, you can write it up in a few sentences for me to test even if you don't have a full repro now.

Regards,
Marin Bratanov
Progress Telerik

Hi René,

How do you reproduce this? I tried adding a grid that is very slow to get its data and toggle between views while it is loading, but I don't get any errors. I am attaching here the code and a video from my tests that shows what I tried. My first explanations on "blocking the thread" are too succinct in the video - I meant that when this wait happens during pre-rendering it will have to wait until it can actually do the render. I don't think that's related to this issue, though.

Judging from this, it looks like somehow the component (page) got to the point where JS Interop can be registered (OnAfterRenderAsync for the grid component) and the grid initialized its reordareble/resizable functionality. Why would the framework have disposed its objects at that point is beyond me, and it looks like an issue with the component lifecycle - at this point there is no proper method for disposing things when a component is removed from view, and the Dispose() method is not always suitable because it is not guaranteed when it will fire. You can read more about this here: https://github.com/dotnet/aspnetcore/issues/13026

That said, if I can reproduce this error, we could look into it to see if there might be anything we can do to avoid it (although another one that depends on it here can't be). Does this exception break the app, or does it only show in the logs?

Regards,
Marin Bratanov
Progress Telerik