Clarity Tabs - Lazy loading?

[JeTmAn1981]

So when it comes to tabs and lazy loading, it appears you have the option to either:

1. Don't load the tab contents until the tab is clicked on. Use the *clrIfActive directive for this. Also used for specifying a default tab to show. Every time you switch to a different tab, the last tab is destroyed and the new one initialized.
2. Let every tab initialize simultaneously. As you switch through tabs, they persist and are only initialized once.

Am I understanding this correctly?

What I'd like is something in between. I want the ability to specify which tab should show by default, but I also want each tab's content to only be initialized exactly one time, when I click on that tab. The reason is because I want to persist some changes between tabs. I have tabs which are different views on the same data, but for various reasons I have change events set up which are needed to persist those changes over to the other tab. That doesn't work if the tabs are destroyed and initialized every time you switch. The changes are lost.

How can I do this?

[Jinnie]

If you separate the view lifecycle from the data model loading, you can have a service that makes the network calls, preloading, caching, etc, as you may like it. Then only leave the data visualization to the tabs contents.

[JeTmAn1981]

I don't think I follow...currently my components all know how to load their own data; this was done to get each component loaded as quickly as possible; as soon as the data specific to that component is ready, we can show it to the user.

How does your suggestion help me to delay loading of the component and its data until its corresponding tab is clicked on, while also allowing me to specify a default tab to show?

[bbogdanov]

@JeTmAn1981 Just don't hold the data inside a component.

Use a service to manage all the needed information and when a component loads(ngOnInit) just get the data from the service. The service can be a single point of truth and that way you won't be worried about components destruction because the data handler/holder is the service.

Another approach can be to use static tabs and the Angular router and plug yourself in the middle of the routing(by using the router hooks). https://stackblitz.com/edit/clarit-tabs-with-router-static?file=src%2Fapp%2Fapp-routing.module.ts

From experience holding data logic inside a component almost always is not a good idea. Sometimes there is a need to delegate the data from a larger component to smaller components and that can be accomplished with dummy and smart components approach.

[JeTmAn1981]

Ah, I see what you mean. I actually am caching component data in services currently, though there's a further wrinkle in this case...I am using the tabs to contain reactive form groups. The tabs in my application present different views/layouts of the same data, so each of the components inside a tab actually has its own instance of the same formgroup (provided by a shared service, to make sure the formgroup created will match).

So when the components are blown away, my data persists, but the formgroups don't. And the way I've got things working, when each component loads it gets its data and loads it into the formgroup, and from that point the formgroup is the source of truth. So when I lose that formgroup, I lose any changes that were made to that data.

Since I need to be able to persist changes between tabs, I'm not able to do that when the formgroup in the other tab doesn't exist behind the scenes but is only instantiated when I actually click on its tab.

But I could still do what you're suggesting...if I saved a persistent copy of the formgroup created for each tab. I think that would work.

So I might try that, though I was really hoping for a way of using Clarity Tabs itself to accomplish what I want.

I'll look into the static tabs idea as well. Thanks for the suggestions.

[bbogdanov]

We try to keep our components stateless as possible.

The are numerous possibilities of what the user can do with a component and we are more likely to block the user to accomplish what he/she is look for by managing a state.

Also there are memory and performance complications that come with state management and I believe the last think you want to do is to deal with a memory or performance issue caused by a component library.