Consolidate Component Level clientlib

[sarah_la]

Hi Everyone,

I have an requirement where I need to load all component level clientlib on a page once. eg. If I have 10 components on a page having 10 clientlib loading respectively then I want to consolidate them together and load once as a dependency at page level (not template level).

1. What is the correct approach to implement this? 
2. Which servlet is responsible to modify this request?
3. I'm thinking of using filter here, if that suits - where in flow I have to?

Appreciate your help!

@lukasz-m  @Jörg_Hoh @Vijayalakshmi_S @Peter_Puzanovs 

[Ritesh_Mittal]

Hi @sarah_la ,

Component level client library will be included on your page as soon you configure the component on the page. Hence, consolidation of all them again does not make any sense.

Since you mentioned that you want to make them as a dependency to another clientlib so-

Are those 10 component also dynamic in nature, means there are number of components and any of them can be used on the page and all respective clientlibs you want to consolidate and make as dependency?

One easy way to achieve this would be to add clientlib in footer or at last which is dependent on those clientlib.

You can also add the dependency of each of those client libraries to the custom clientlib dependent one.

Thanks,

Ritesh Mittal

[sarah_la]

@Ritesh_Mittal I know that clientlibs loads when you configure components - I want to consolidate because to reduce number of requests instead of 10 (If I use 10 components on a page) - Make sense?

That's correct - basically instead of 10 requests make one request and load all other clientlib by consolidating them as a dependency.

To reply your answer - One easy way to achieve this would be to add clientlib in footer or at last which is dependent on those clientlib. 

This can be loaded always even if I don't use component.

Hope you understand my question correctly now.

Thanks!

[Jörg_Hoh]

There is no good approach to achieve that during page rendering, because it would require a 2-pass rendering: First you need to build the complete dependency/component tree and extract the required clientlibs; in a 2nd pass you would render this tree.

Implementing this in a framework-alike style would require a major redesign/rewrite of the sling rendering process, especially because the dependencies cannot get calculated only by looking at the resource tree.

[sarah_la]

@Jörg_Hoh - That's exact implementation I'm looking for - ready to redesign! as you said above

1. Fetching component tree based on resource type and their clientlib respectively.

2. consolidate them and render on to the page.

so, where and how to start? do you think Sling Filter works here?

[Jörg_Hoh · Accepted solution]

The problem is that the resource tree is not enough (in the generic case). Your resource tree might reference a component which pulls in content from a resource outside of the rendering tree. Unless you know all of these components and you know which "external" resources they are pulling in (recursively), it won't work reliably.

To make this work, you would need to redesign the complete Sling rendering process, and split the "include" from the "render" part.

Of course you could write a filter, which renders the rest of the page into an in-memory buffer; instead of writing the clientlib inclusions directly, you would write them into a request attribute, and when the control returns to that filter, you write all of these inclusions into the output, followed by the rest of the buffered response. That might work, but it wil break all streaming, and you might run into memory problems (if you have large responses), and deliver a really bad TTFB (if measured from AEM).