I have a Blazor page with a RadzenTabs control on it with a few tabs. The first tab contains a component which contains a RadzenGrid which loads up data when loaded. When I switch to another tab and then back to the first, that component reloads as if it had been disposed and was just now initializing.
This behavior doesn't occur when using a Tabs control from another vendor. The component which contains the RadzenGrid only initializes once.
Yes, the behavior you have observed is by design. The RadzenTabs renders only the current tab contents. Similar to this example from the Blazor documentation.
Render, yes. That's the behavior of a tab. But if the component within the tab is totally disposed then I have to hit the API and thus database again when it is re-instantiated just to get the data back that was previously loaded, unless I send the data up to the parent component to cache and then pass it back to the child component when it's re-instantiated.
I overcame this issue by creating a Tabs state service class that holds the data state of each tabs item so the data is not lost on the change of index and the tab item redraws.
I know this is the design of the component and in most cases for us it's fine, However we're loading a Radzen chart in under it, and what's happening is the chart is being disposed and recreated each tab change which takes about 2 seconds to display.
I mean obviously I can make my own tabs and just have it mark them as hidden and not after, But we've designed all of our pages with Radzen at this stage, it's not a great decision to make it ourself and change the other pages.
It would seem that having the component offer both ways would let people choose speed vs memory usage.
We're using the Wasm version, But yes I've tried both options, I've only just found the source for the RadzenTabs and am having a look in case there's a real easy fix.
We have 2 tabs, 1 is a small amount of data, 1 is a decently heavy chart
With Client Rendering switch between the 2 tabs takes 1-2 seconds, that's back and forth constantly doing it 5 times back and forth.
With Server Rending switching to the light content tab is perceptively instant, vs the heavy tab which takes 1-3 seconds, Seems a smidge slower than the Client rendering,
But that's the same testing, back and forth it just keeps doing the same, 1-3 for the heavy, instant for the light tab.
Perhaps the client version delay could be the browser lagging as it marks the Div to be hidden, As I understand it, it doesn't reload when set to Client.
And that could be the chart being significant.
The chart has 5 series that have 500 datapoints each, Not crazy, But enough to make it stutter
I tried it in SyncFusion too in case their chart was faster, but it was far slower.
If we need to I can reduce the resolution of the datapoints, but I wanted to check for performance benefits first before slimming the data.
This behaviour being by design is an absolute deal breaker for all of the reasons others have listed on this post. I do not want my component created and destroyed on each tab change. It is just going to pound the server for data, and I don't want the parent component to have to maintain all of the data for all of the tabs and their sub-components. Why destroy the tab's when changing to a different tab? I'd think just leaving the content along would make the most sense.
Just to add my two cents on this tab issue once again.
The RenderMode did not affect the time it took for the tab to render in my .NET Core 3.1 Blazor Server application. The only difference was that with Client set, the entire modal would take more time to render at first, but tab navigation would still be slow for whatever reason. My results are very similar to @Biztactix and the tests were done using a grid instead of a chart.
Now it's even worse. It's taking an extra time to render the dialog (because of client mode ofc), but every tab takes many seconds to render, longer than before.
Here's how it was with RenderMode set to Server before this recent change: