MWPW-199014: Dynamic imports in studio.js#998
Conversation
|
Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch.
|
|
SNOW Change Request Transaction ID [STUDIO]: 0000019c1ef37582-14975439 |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #998 +/- ##
==========================================
- Coverage 90.00% 89.46% -0.55%
==========================================
Files 283 292 +9
Lines 90410 91844 +1434
==========================================
+ Hits 81374 82164 +790
- Misses 9036 9680 +644
... and 12 files with indirect coverage changes Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
|
@mirafedas the followings are still to be deferred because they import other files: https://mwpw-444444--mas--adobecom.aem.live/studio/src/editors/merch-card-collection-editor.js |
There was a problem hiding this comment.
This should also be refactored to use the getFragmentPartsToUse function from utils.js. Otherwise statically importing editor-panel.js would eagerly load it including its tree of dependencies which would defeat the purpose of reducing the resource fetches via lazy loading.
There was a problem hiding this comment.
In fact, mas-promotions-editor:14 should also be refactored accordingly to avoid the eager loading of editor-panel.js.
| openCreateDialog() { | ||
| async openCreateDialog() { | ||
| if (!customElements.get('mas-create-dialog')) { | ||
| import('./mas-create-dialog.js') |
There was a problem hiding this comment.
Shouldn't this await the import? Otherwise this.createDialogOpen = true is set before the element is defined.
honstar
left a comment
There was a problem hiding this comment.
Can you explain why the ./rte/rte-field.js imports are needed?
Resolves https://jira.corp.adobe.com/browse/MWPW-199014 .
In studio/src/studio.js — added lazy-load page components
Replaced 14 eager static imports (one per page component) with a #lazyLoad(elementName, importPath) helper called from each page getter. Each getter now fires import() on first render for its page, waits for customElements.whenDefined() to schedule a re-render, then returns the template on the second pass.
Additionally:
In studio/src/translation/translation-utils.js —fixed the import source
getFragmentPartsToUse was imported from editor-panel.js. Because editor-panel.js is now lazy-loaded (only on PAGE_NAMES.CONTENT), keeping that import would pull editor-panel.js into the bundle eagerly, defeating the lazy-load entirely. The import was redirected to utils.js, which already exported the same function. The call signature changed accordingly: utils.js takes (fragment, path) while editor-panel.js took (store, fragment).
In studio/src/editor-panel.js — aligned promotion field with utils.js
This change is needed because redirecting translation-utils.js to utils.js created a silent inconsistency: utils.js used fragment?.getCurrentTagTitle?.(TAG_PROMOTION_PREFIX) for the promotion field, while editor-panel.js (still used by the editor panel itself and mas-fragment-editor.js) used the older fragment?.getTagTitle(TAG_PROMOTION_PREFIX).
The two methods differ: getTagTitle reads from the fragment's original tags array (initial state), while getCurrentTagTitle reads from the tags field values, which reflect in-flight edits the user has made but not yet saved. After the translation-utils.js redirect, the translation table and the editor panel could show different promotion labels for the same fragment — getCurrentTagTitle on one surface, getTagTitle on the other. Aligning editor-panel.js to getCurrentTagTitle?.() makes all three surfaces consistent.
QA Checklist: https://wiki.corp.adobe.com/display/adobedotcom/M@S+Engineering+QA+Use+Cases
Please do the steps below before submitting your PR for a code review or QA
🧪 Nala E2E Tests
Nala tests run automatically when you open this PR.
To run Nala tests again:
run nalalabel to this PR (in the right sidebar)To stop automatic Nala tests:
run nalalabelTest URLs: