Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Multiple CQ component with component group .hidden

avinasht7298469
Level 2
Level 2

I am reviewing the implementation for a client ,in which they have 500 hidden component .

one example of why the component count for hidden component is  high.

Headline component: This component is hidden .(/apps/headline)

teaser 1: here we are including headline component which is under teaser component (/apps/teaser1/headline1)

teaser1/headline1(/apps/teaser/headline1) :This component inherits from (/apps/headline) but has extra properties related with css and js as properties on this node .

teaser2:here we are including headline component which is under teaser component (/apps/teaser2/headline2)

teaser2/headline2(/apps/teaser2/headline2) :This component inherits from (/apps/headline) but has extra properties related with css and js as properties on this node which are used while we are displaying the code.

This is one way of implementation but you can remove these extra headline2,headline1 component by using cq:template and specifying these css and js property.

Based on my experience we used cq:component node only when we have to use reuse the component in other component or use sling inheritance ,if the component are not reused best way is to using include script or synthetic resource.

what would be the impact of using such high number of hidden component and is it in align with adobe best practice?

1 Accepted Solution
Jörg_Hoh
Correct answer by
Employee
Employee

Hi,

500 components are too much. really. too. much. No matter if they are hidden or not. It's basically a nightmare from a maintenance point of view.

Instead of having very much very specialized components I would rather make individual components more powerful (and yes, probably a bit more complex). But in the end it usually papys off in terms of flexibility (no need to remove a component A and replace it with a component A*) and maintenance work (can you really test all components? What about combinations of them?).

From a performance point of view I don't think that the large number of components is a problem. There's a small impact (every include of a component triggers the component filters), but that should be neglectable.

Jörg

View solution in original post

1 Reply
Jörg_Hoh
Correct answer by
Employee
Employee

Hi,

500 components are too much. really. too. much. No matter if they are hidden or not. It's basically a nightmare from a maintenance point of view.

Instead of having very much very specialized components I would rather make individual components more powerful (and yes, probably a bit more complex). But in the end it usually papys off in terms of flexibility (no need to remove a component A and replace it with a component A*) and maintenance work (can you really test all components? What about combinations of them?).

From a performance point of view I don't think that the large number of components is a problem. There's a small impact (every include of a component triggers the component filters), but that should be neglectable.

Jörg

View solution in original post