Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.

Code Review for Sightly component

Avatar

Level 2

Is there any code quality check tool available for component development in sightly? Even a checklist or best practice deck would help. What is the best approach for reviewing/checking code quality of a sightly component ?

6 Replies

Avatar

Level 10

Check the HTL (not named Sightly anymore) spec:

https://github.com/Adobe-Marketing-Cloud/htl-spec/blob/master/SPECIFICATION.md

There isn't a tool that checks code. 

Avatar

Level 10

If you are looking to build a HTL component that uses the WcMUsePojo Java class -- see: 

http://scottsdigitalcommunity.blogspot.ca/2016/07/creating-aem-html-template-language.html

There are links here to 6.1, 6.2, and a video. 

Avatar

Administrator

I do not think so that there is some tool to validate this.

But, best practice is to use AEM HTL/Sightly Brackets Extension. You can install this extension on Brackets if you plan to use HTL (Formerly known as Sightly) as the markup. The extension provides you with features such as syntax highlighting and code completion. Brackets extension provides front-end developers an AEM templating tool with which they are familiar. The idea is to bring more front-end developers to AEM template designing.

Documentation : https://docs.adobe.com/docs/en/dev-tools/aem-brackets.html

Thanks and Regards

Kautuk Sahni



Kautuk Sahni

Avatar

Level 10

To further add to what Kautuk suggested - watch this Ask the AEM Community Experts session:

https://communities.adobeconnect.com/p72w6ea9pf1/?launcher=false&fcsContent=true&pbMode=normal

It talks about Brackets/HTL development. 

Avatar

Employee

Couple of things from my side:

- try to use the expressions first, rather than writing code

- some logic can be written in just a couple of lines in JavaScript

- if you need to write code use SlingModels, WCMUsePojo is harder to reuse/test

- avoid <sly />, data-sly-unwrap and stick with the HTML output that you want