Receber por email
← Voltar para o catálogo

sf-b2c-sfra

Build B2C Commerce storefronts with SFRA (Storefront Reference Architecture) — cartridge overlay system, MVC pattern, app_storefront_base, module.superModule inheritance, middleware chain, and site-specific customizations. Use when developing SFRA-based storefronts.

34estrelas
Atualizado há 5 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add OrcaQubits/agentic-commerce-skills-plugins

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/sf-b2c-sfra/svg)](https://www.skillteca.com.br/skills/sf-b2c-sfra)

Alerta por categoria

Receba novas skills de Design e Frontend toda segunda

1 email curto, só com as skills novas de Design e Frontend. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Salesforce B2C Commerce SFRA Development

Before Writing Code

Fetch live docs:

  1. WebFetch github.com/SalesforceCommerceCloud/storefront-reference-architecture for SFRA source
  2. Web-search site:developer.salesforce.com SFRA architecture MVC for MVC patterns
  3. Web-search site:developer.salesforce.com SFRA cartridge overlay for overlay best practices
  4. Web-search site:developer.salesforce.com module.superModule for extension patterns
  5. Web-search site:developer.salesforce.com SFRA getting started for latest docs

Conceptual Architecture

SFRA Overview

SFRA (Storefront Reference Architecture) is the reference implementation for B2C Commerce storefronts:

  • Server-side MVC -- Models, Views (ISML), Controllers
  • Cartridge overlay system -- stack custom cartridges on top of base
  • module.superModule -- extend base functionality without copying code
  • Client-side build -- Webpack bundles JS and SCSS
  • Page Designer -- visual page building with reusable components

Four Key Principles

| Principle | Rule | |-----------|------| | Overlay | Never modify app_storefront_base -- create custom cartridges that layer on top | | Extend | Use module.superModule to inherit and augment, not replace | | Hooks | Use commerce hooks for order, payment, and shipping customization | | Services | Use the Service Framework for external integrations (payment gateways, ERP) |

Cartridge Path Resolution

The cartridge path (configured in Business Manager) resolves files left-to-right. The leftmost cartridge wins.

Example path: app_custom:app_storefront_base

  • Request for controllers/Product.js checks app_custom first, falls back to app_storefront_base
  • Templates, models, and scripts follow the same resolution

Cartridge Directory Structure

app_custom/cartridge/
├── controllers/        # Route handlers
├── models/             # Data models
├── scripts/            # Helpers, services
├── templates/          # ISML templates
├── experience/         # Page Designer
└── client/default/     # JS + SCSS source (Webpack)

module.superModule

module.superModule resolves to the next cartridge in the path that provides the same module. This is how you extend without duplicating:

  • Controllers: var base = module.superModule; server.extend(base); then use append/prepend/replace
  • Models: Call base constructor with base.call(this, apiProduct, options), then add properties
  • Scripts: Import base, extend functions, re-export with spread

MVC Pattern

| Layer | Location | Role | |-------|----------|------| | Controller | controllers/*.js | Route handling via server module | | Model | models/**/*.js | Transform API data to view-friendly objects | | View | templates/default/**/*.isml | ISML templates for HTML rendering | | Client JS | client/default/js/ | Browser-side behavior (Webpack bundled) | | SCSS | client/default/scss/ | Styles (compiled to CSS) |

Extend vs Replace Controllers

| Approach | When | Trade-off | |----------|------|-----------| | server.extend(base) + append | Adding data, logging, analytics | Keeps base logic; auto-receives base updates | | server.replace('Route', fn) | Fundamentally different logic | You own the entire implementation; no base updates |

Prefer extend + append in nearly all cases. Only replace when the base logic is wrong for your use case.

Client-Side Build

SFRA uses Webpack to build client assets from client/default/js/ and client/default/scss/. Output goes to cartridge/static/default/. Client JS can extend base modules:

// Pattern: Extend base client module
var base = require('base/product/detail');
// Fetch live docs for base module API

Site Preferences and Custom Objects

  • Site Preferences: Site.getCurrent().getCustomPreferenceValue('prefName') -- store-level configuration
  • Custom Objects: CustomObjectMgr.getCustomObject('Type', 'key') -- custom data structures
  • Both are managed in Business Manager and accessed via dw.* API

Best Practices

Cartridge Overlay

  • Never modify app_storefront_base
  • Name custom cartridges consistently: app_custom_[sitename] or int_custom_[feature]
  • Use module.superModule to extend -- avoid code duplication
  • Test overlays after base cartridge updates

Controllers and Models

  • Use server.extend() to inherit base routes
  • Keep controllers thin -- move logic to models and scripts
  • Call base model constructor, then add properties
  • Always call next() in middleware chain

Templates and Client Code

  • Use <isinclude> for reusable components
  • Use resource bundles for all text: Resource.msg('key', 'bundle', null)
  • Import and extend base client JS modules
  • Minimize jQuery -- prefer vanilla JS for performance

Security and Performance

  • Use Transaction.wrap() for all database writes
  • Encode output in templates to prevent XSS
  • Use CSRF tokens for state-changing operations
  • Cache expensive operations via CacheMgr

Fetch the SFRA GitHub repository, developer documentation, and module.superModule guide for exact patterns, API references, and best practices before implementing.

Compartilhar X LinkedIn