Clientlib Loading Order Breaks a Dialog Widget After Upgrade
After an AEM upgrade, a custom rating-widget used inside a component dialog stops initializing. The widget's JS is in a clientlib category myapp.widgets with dependencies=[myapp.base]. The dialog includes it via extraClientlibs on the cq:dialog node. The console shows TypeError: Cannot read properties of undefined from the widget's init, and the Coral UI dialog renders but the widget is inert. The myapp.base clientlib embeds jQuery and a polyfill. On the page (non-dialog) the same widget works. There are no 404s. The upgrade changed the dialog framework to a newer Coral version.
1. Diagnose why the widget initializes on the page but not in the dialog, and what the `extraClientlibs`/dependency setup implies.
Read the worked answer
The page and the dialog load clientlibs through different mechanisms. On the page, myapp.base (with jQuery and the polyfill) loads before myapp.widgets because of the declared dependency, and the widget's init finds its expected globals. In the dialog, extraClientlibs loads the category into the dialog iframe/context, and the newer Coral version may load its own scripts in an order that places myapp.widgets before myapp.base-or the dialog context does not honor the same dependency chain the page does. The TypeError on init reading an undefined property is consistent with the widget running before its dependency (jQuery/polyfill) is defined, or against a Coral API that changed shape.
The absence of 404s rules out missing files. The fact that only the dialog breaks points at load order and context, not at the widget logic itself. extraClientlibs is the right hook, but it must be paired with a category whose dependency graph guarantees myapp.base first; if the dialog framework injects categories without resolving dependencies, the order is not guaranteed.
2. Propose a fix and a way to confirm ordering without relying on visual inspection.
Read the worked answer
Fix in two parts:
- Guarantee order: either make
myapp.widgetsdeclaremyapp.baseas a dependency and confirm the dialog loads the dependent category (not a flattened bundle that drops the chain), or create a dedicated dialog categorymyapp.dialog.widgetsthat embedsmyapp.basefirst and then the widget JS, and pointextraClientlibsat it. Embedding removes runtime ordering ambiguity. - Harden
init: guard against undefined dependencies and defer initialization until the dialog'sfoundation-contentloadedevent, which the newer Coral framework fires; initializing on script load is fragile.
Confirm ordering without eyeballing: open the dialog, inspect the Network tab and check the script request sequence for myapp.base before myapp.widgets; or add a temporary console.log at the top of each file and read the order in the console. Better, add a unit-style check in the widget that throws a clear message if its dependency is missing, so the failure names the cause. Re-test on a page that opens the dialog from a component instance, not just the component's standalone preview.