Developing new site using out of the box components

[LizFa]

We are in AEMaaS. My team will be developing a new project and is considering using out of the box teaser component to potentially create 2 other components that would leverage that code (they would have the same dialog as the teaser component except limited style options specific to that use case) and these additional components would be renamed to showcase how it would be used, for example: ‘card component’ or ‘hero banner component.’  The thought is that this would be easier for an author to understand what type of component it is, but also from a UI development perspective. It would be easier to modify a component that has less options associated with it.

My questions:

• if we go that route, would future AEM upgrades that affect the teaser component be reflected in these additional components that leverage the same code?
• Has anyone done something similar and ran into issues?  

Any insights and shared experiences would be greatly appreciated!

Thanks

[BrianKasingli]

I currently have experiences with our customers where the teaser component has so many features that its overloaded with too many features, causing confusion for content authors, it’s often referred to as “feature creep” or “overcomplication”.

In this case, moving forward during component development, if there's a bug or a new feature that is done on that same component... it may break other features. But from your requirements of teaser component with card layout and hero layout, it seems like these components are quiet small, and the functionalities are much the same... I would prefer you create a single component and have these two cases covered, but either option works... However, you should speak to your product owner and have him speak to the authors to see what they think is better for them... after all, as AEM engineers, we try our best to ease the lives of the authors.

Note: As your components get more complicated, your author's would need complicated training... if a teaser component has like 5 layout options and 15 style system options, this to lead to the fact that only power authors can author on your website.

Adobe recommends several best practices for creating components to ensure they are effective and user-friendly. One key aspect is indeed to avoid overcomplicating components. Here are some best practices to consider:

- Keep Components Simple and Focused: Each component should have a clear and singular purpose.

- Avoid bundling too many features into one component. This helps prevent complexity and makes it easier for content authors to use and manage.

- Reuse Components: Design components with reusability in mind. Create components that can be used across different pages or sections, and ensure they are modular and flexible. This reduces redundancy and makes maintenance easier.

- Optimize Authoring Experience: Ensure the component authoring interface is intuitive. Use clear labels, provide helpful tooltips, and organize fields logically. Aim for a clean, uncluttered design to minimize cognitive load on content authors.

- Reduce the amount of components: Reducing the number of components can be a key strategy in AEM development to simplify the system and improve the user experience for content authors.

=====

• if we go that route, would future AEM upgrades that affect the teaser component be reflected in these additional components that leverage the same code?

Going into the future, as AEMaaCS improves the AEM Core Components, any new feature enhancements should be less risk. Say you target the Teaser2 core component. If there was an upgrade to this component, it wouldn't be severe. Severe upgrades would introduce a new version like Teaser3, which you would need to change the resourceSuperType and also re-test your Proxied Teaser Component.

Regards,
Brian

[arunpatidar · Accepted solution]

Hi @LizFa 

You can leverage core components (OOTB since AEMaaCS), which ensures that updates won't affect your implementation by using a specific version. You can also create card and hero banner components by extending the Teaser component using the proxy pattern with minimal adjustments.

Check out the core components here: https://github.com/adobe/aem-core-wcm-components/tree/main

For guidance on extending core components for cards and hero banners, refer to this article on the proxy pattern: https://medium.com/@veena.vikraman19/aem-avoiding-delegation-pattern-pitfalls-with-core-components-9...

[kautuk_sahni]

@LizFa Did you find the suggestions helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!