SuiteCommerce Developer: Frontend Customization and Extension Development

Frontend Customization and Extension Development

This domain tests building the shopper-facing layer the supported way - as an extension module rather than edited core files - with a build you can repeat.

How an extension is put together

• A module lives in Modules/<vendor>_<name>/ and ships an ns.package.json whose gulpConfig maps its folders (JavaScript, Templates, Sass, assets) into build output. A path missing there means your file silently never compiles.
• Views are Backbone/Marionette: a CompositeView renders a collection through childView, the events hash binds DOM events, and getContext() feeds the Handlebars template. Keep logic in the view or model, not in the .tpl.
• Override the smallest unit - a template partial or one view method - so a future core release can be merged.
• Test with gulp local against a development account via local.json, then gulp deploy and publish.
• User-visible strings go through the project's translation helpers, not hardcoded English.

Worked example

Add a size-guide modal to the product detail page. Reasoning: it is UI-only, so no backend script is needed. Create an extension, add a template partial and view code that listens for a click on a new link and opens the modal, add Sass for the overlay, list every folder in ns.package.json, run gulp local to confirm the extension is actually served, then deploy and publish. Do not fork the whole ProductDetails view for one button.

Traps

• Editing distro/ or File Cabinet copies; both are build outputs.
• Forgetting to destroy child views and handlers, leaking listeners on every re-render.
• Assuming a deploy published the site - shoppers still receive the old bundle.
• Hardcoding text and currency symbols instead of using i18n and formatting helpers.