1 Reply Latest reply on Dec 7, 2017 1:02 AM by Jörg Hoh

    Multiple CQ component with component group .hidden

    avinasht72984695 Level 1

      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. Re: Multiple CQ component with component group .hidden
          Jörg Hoh Adobe 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

          1 person found this helpful