Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Multiple CQ component with component group .hidden

Avatar

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

Avatar

Correct answer by
Employee Advisor

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

Avatar

Correct answer by
Employee Advisor

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