Creating custom component similar to Tabs / Accordion / Carousel ??

[dylanmccurry]

I am creating a Header component for my site, and would like the authoring experience to mimic the AEM Sites "Tab" component. The content author would put down the primary header component, and then place inside of it's parsys a number of flyout components. Only one flyout is expanded by default in edit mode, and the content author has the ability to toggle which flyout is currently visible for editing purposes.

In this case, my "Header" component is analogous to the "Tabs" component, and the "Flyout" component is analogous to the "Panel" component.

I already have the markup and css worked out for the header. Now I'm porting it to AEM and making it authorable.

Should I:

1. Copy the out of the box Tabs component and rename all occurences of "tab" with "header"
2. Create a new component called "Header" and set it's sling resource super type to the Tab component
3. Something else??

I am basically looking for advice on the best and easiest way to achieve the editing experience of the tab components on my own custom component.

[EstebanBustamante · Accepted solution]

Hi, 

You would need to use the "children editor", here is an excellent and detailed article about how to use this in a custom component: https://aemlab.blogspot.com/2022/09/aemaacs-core-components-children-editor.html 

Hope this helps

[dylanmccurry]

Thanks, this is definitely what I am looking for!

One quick clarifying question... there appears to be a dependency on a handful of abstract classes that are internal to the core components. For instance, these: https://github.com/arunpatidar02/aemaacs-aemlab/tree/master/core/src/main/java/com/community/aemlab/... appear to be replicated from these: https://github.com/adobe/aem-core-wcm-components/blob/main/bundles/core/src/main/java/com/adobe/cq/w... 

... is there no way to simply inherit from the core functionality? Instead, the recommended path is to copy and maintain a local version of the same thing?

[kapil_rajoria]

Hi @dylanmccurry,

At one point, I also came across a similar requirement. The HTML design included tabs, and a particular tab's content contained a multifield inside another multifield. To enhance the authoring experience, I wanted to enable toggle functionality. So, I decided to use OOTB tabs component.
I was also unsure whether to overlay or override the Tabs component or create a completely separate component while reusing the existing HTML, CSS, and JS from the OOTB implementation.

Here are my insights from that experience:

1. Overlaying or Overriding the Tabs Component

   If you choose this approach, carefully review the OOTB Tabs component's HTML and JS. If your HTML structure differs significantly, integrating the existing JS functionality can be very challenging since it is specifically written for the OOTB component.

2. Creating a Separate Component

   If you opt for a completely separate component, ensure that your HTML structure closely matches the OOTB Tabs component.This allows you to easily reuse its existing JS functionality without major modifications.

In my case, my custom HTML was completely different and I still forcefully tried to make it like OOTB HTML by using the same classes and HTL expressions. It took a huge amount of time and efforts. In the end, the component still didn't work and had a lot of bugs. My main concern was the JS files, the OOTB is having. Properly study them, before beginning your work.