The post addresses common pitfalls when extending AEM component dialogs with custom JavaScript code. As projects scale and multiple components accumulate, complexity grows and custom JS can break logic in other dialogs.
“Every custom include of ‘extraClientlibs’ will live on the page until page reload therefore JS functions could easily break logic in other dialogs during the page editing.”
1. Avoid Including Everything in cq.authoring.dialog
The cq.authoring.dialog category should reserve space only for utility methods applicable across all dialogs without causing conflicts.
2. Use Separate, Descriptive Categories
Create distinct categories using package or folder paths to prevent name collisions:
1
categories="[project-a.components.product.wizzard.authoring]"
3. Add Dialog Validation Logic
Implement resource type verification at the beginning of custom JS to ensure code executes only in the intended dialog:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
(function (document, $) {
"use strict";
const DIALOG_RESOURCE_TYPE = "project-a/components/product/wizzard";
function isTargetDialog($formElement, dlgResourceType) {
const resourceType = $formElement.find("input[name='./sling:resourceType']").val();
return resourceType === dlgResourceType;
}
$(document).on("dialog-ready", function () {
const $formElement = $(this).find('coral-dialog form.foundation-form');
if (!isTargetDialog($formElement, DIALOG_RESOURCE_TYPE)) {
console.debug("Skip the listener, not a ", DIALOG_RESOURCE_TYPE, " dialog.");
return;
}
// Implementation code here
});
})(document, Granite.$);
These practices promote maintainable, scalable dialog implementations across growing AEM projects.