feat(tabs): add lazy loading for tabpanel content

[Adrii77]

Defect Fixes

#16806
#17351

This PR add lazy loading for the desired tabpanel's projected content.

Inactive tabs are hidden([hidden]="!active())".
initialized signal is used to render content the first time the tab is active and prevent re-initalization on reselection. Maybe a linkedSignal could be used, but I write the code the be compatible with NG 18.
It could be really cool if this PR could be merged and available in a patch version on 18, since apps that migrate to Prime 18 end up with complex components instantiated inside inactive tabs... (this is my case)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

2 Skipped Deployments

Name	Status	Preview	Updated (UTC)
primeng	⬜️ Ignored (Inspect)	Visit Preview	Jan 14, 2025 7:41pm
primeng-v18	⬜️ Ignored (Inspect)	Visit Preview	Jan 14, 2025 7:41pm

[vercel]

Someone is attempting to deploy a commit to the primetek Team on Vercel.

A member of the Team first needs to authorize it.

[ArnaudFelixParis]

LGTM

[mertsincan]

Hi @Adrii77, thanks a lot for your PR! I think we can add lazy property for this feature in two components;

1. In p-tabs component to configure globally
2. In p-tabpanel component to configure self-decision

WDYT?

[Adrii77]

Hi @mertsincan ,

Thank you for your answer and for your time :)

My opinion :

1. Provide an ng-template is a self decision : you want a tab with lazy loading ? just project your content inside an ng-template. You want another tab without lazy loading ? don't encapsulate it.
2. Smaller and simpler API, as we don't need to add an extra input for this behavior.
3. Easier migration : with the old TabView component, lazy loading was working with ng-template. After migration to the new Tabs component, devs has just to remove pTemplate="content" from ng-template to keeping lazy loading.
4. Today, applications that migrate to Prime 18 find themselves with a feature regression and a drop in performance, since lazy loading no longer exists. In my case, I have a page with 5 tabs which two of them contains a complex stateful component (with http calls). Even if one of those tab isn't active, components are initialized and backend calls are triggered.

With this PR, lazy loading is preserved and prevents this regression (working with my test, hope you'll test too !). I think in any case it would be wise and pragmatic to have lazy loading this way to prevent this feature regression and why not refactor later if you want to find a way to do it via inputs.

What do you think ? :)