SAP Spartacus Documentation

repository·develop·Indexed 20 days ago

https://github.com/sap/spartacus

A lean, Angular-based JavaScript storefront for SAP Commerce Cloud that communicates via Commerce REST APIs. It includes a core library, schematics for automated installation and migration, and specialized packages such as @spartacus/assets for static resources, @spartacus/setup for recipes, and @spartacus/skills for AI Agent development. Designed to be PWA-ready, extendable, and upgradable.

Tokens
355.6K
Snippets
1.3K
Records
2.1K
Agent score
73%

What's inside Spartacus

  1. What is Spartacus?

    develop

    Spartacus is a lean, Angular-based JavaScript storefront designed for SAP Commerce Cloud. It communicates with the backend exclusively through the Commerce REST API.

    Key characteristics include:

    • Extendable: Designed to be upgraded while maintaining full extendability through libraries.
    • Upgradable: Published as libraries following semantic versioning.
    • Progressive: Aiming for full Progressive Web Application (PWA) compliance.
    • Open Source: Developed by the SAP Commerce Cloud team with community contributions welcome.
  2. S/4 HANA Synchronous Order Management capabilities

    develop

    The s4om integration library provides S/4 HANA Synchronous Order Management features to the Spartacus UI. It enables the following capabilities:

    • Schedule Lines: Displays a table in the B2B Cart showing scheduled delivery dates and product quantities for each item, sourced directly from the S/4 HANA system.
    • Requested Delivery Date: Allows customers to specify a preferred delivery date for items. The library fetches the minimum allowable date from S/4 HANA to validate the request alongside the Order.
    • PDF Invoices: Enables users to view and download order invoices. The system uses Invoices APIs where the backend returns a byte array that is converted into a downloadable PDF file.
  3. Use Spartacus recipes and schematics for streamlined setup

    develop

    The @spartacus/setup library provides tools to simplify the configuration and integration of Spartacus feature libraries. It focuses on two main areas:

    1. Recipes (@spartacus/setup/recipies): Provides common Spartacus recipes that include a default set of modules and pre-defined configurations to get your application running quickly.
    2. Schematics (@spartacus/setup/schematics): Provides Angular schematics designed to automatically configure different Spartacus feature libraries so they work together seamlessly without manual wiring.
  4. Use Spartacus Storefront to add default features

    develop
    Spartacus Storefront is a package designed to be included in your application to provide a set of default storefront features. It is built to be extendable and upgradable by updating the library version. To customize the visual appearance of the storefront, use the @spartacus/styles package.
  5. Use Spartacus Styles for global styling and theming

    develop
    Spartacus Styles is a styling library designed to provide global styling and theming for the @spartacus/storefront. It is intended to be used in conjunction with the Spartacus Storefront to build eCommerce platforms that interact exclusively with SAP Commerce Cloud via the Commerce REST API.
  6. What is the Spartacus Core Library?

    develop
    The Spartacus Core Library serves as the foundational building block for the Spartacus ecosystem. It provides essential core features that are required by all other Spartacus libraries (such as @spartacus/cart, @spartacus/checkout, etc.) to function correctly.
  7. What is the Proxy Facade Pattern in Spartacus?

    develop

    The proxy facade is an eager-injectable abstraction used to bridge the gap between eager code and lazy-loaded feature modules. It allows components to inject(ActiveCartFacade) immediately, even though the actual implementation resides in a separate lazy chunk.

    How it works

    1. The Abstract Facade: An abstract class (e.g., ActiveCartFacade) is declared in an eager @spartacus/<feature>/root module. This provides the stable contract for consumers.
    2. The Proxy Provider: A useFactory provider is registered in the root module using facadeFactory. This factory returns a stub object that:
      • Triggers the lazy chunk for the specified feature if not yet loaded.
      • Once loaded, retrieves the real implementation from the lazy injector.
      • Forwards method calls to the real instance.

    Critical Constraint: Async Only

    Because the proxy must wait for lazy chunks to load, proxy facades must only expose methods that return Observables. They must never expose synchronous methods or plain value properties, as a synchronous getter cannot wait for the chunk to load.

    // Example of the two pieces
    
    // 1. The abstract Facade class (Eager)
    export abstract class ActiveCartFacade {
      abstract getActive(): Observable<Cart>;
      abstract getEntries(): Observable<OrderEntry[]>;
      abstract addEntry(productCode: string, quantity: number): void;
      abstract removeEntry(entry: OrderEntry): void;
    }
    
    // 2. The proxy useFactory provider (Eager)
    @Injectable({
      providedIn: 'root',
      useFactory: () =>
        facadeFactory({
          facade: ActiveCartFacade,
          feature: CART_BASE_CORE_FEATURE,
          methods: ['getActive', 'getEntries', 'addEntry', 'removeEntry'],
        }),
    })
    export abstract class ActiveCartFacade { /* ... */ }
  8. Understand the relationship between Spartacus and Composable Storefront

    develop

    As of version 5.0, the official release of the Spartacus libraries published by SAP is named SAP Commerce Cloud, composable storefront.

    • Composable Storefront: The officially supported version for SAP Commerce Cloud customers. It is included in the SAP Commerce Cloud license at no extra cost and follows a roll-forward update policy.
    • Spartacus Open Source: The underlying open-source code. On-premise customers can continue to use the Spartacus open-source libraries independently.
  9. Customizing and extending Spartacus

    develop

    To ensure upgradability, Spartacus follows a specific design pattern:

    1. Core Libraries: Use the provided Spartacus libraries for core resources and SAP Commerce integration.
    2. Feature Libraries: Build non-core features as separate libraries that add to or change existing functionality rather than modifying the core code directly.
    3. CMS-Driven Content: Content for pages (logos, links, banners, static pages) should be fetched from the SAP Commerce Cloud CMS. New features should follow this pattern to allow Content Managers to manage content via CMS tools.
  10. Choose the correct state management pattern in Spartacus

    develop

    When customizing or extending a Spartacus feature, you must match the existing state management pattern used by the @spartacus/* library for that specific feature. Do not introduce a third pattern (like a plain BehaviorSubject) if a pattern already exists, as this breaks caching, SSR transfer-state, and event integration.

    Pattern Selection Guide

    1. NgRx Pattern: Uses Actions, Effects, Reducers, and Selectors. Facades dispatch actions and select from the store.

      • Used by: Product, Cart, CMS, Auth, and Site Context.
    2. Commands/Queries Pattern: Uses CommandService and QueryService. Commands handle imperative operations, while Queries manage state via QueryState<T> (including loading, error, and data states).

      • Used by: Checkout, User Account, User Profile, Quote, and Customer Ticketing.

    How to detect the pattern

    To determine which pattern to follow, inspect the facade's service implementation within node_modules/@spartacus/:

    • If the facade dispatches NgRx actions and selects from the store $\rightarrow$ use NgRx.
    • If the facade uses CommandService or QueryService $\rightarrow$ use Commands/Queries.
  11. Understand the Spartacus library structure

    develop

    Spartacus libraries follow a specific directory structure designed to optimize loading via EAGER and LAZY loading. When developing or extending a library, follow this organization:

    • root/ (EAGER): Always loaded. Use this for abstract facades, models, events, tokens, configs, and routes.
    • core/ (LAZY): Business logic. Use this for facade implementations, connectors, NgRx store, and abstract adapters.
    • components/ (LAZY): UI elements. Use this for components, guards, and context providers.
    • occ/ (LAZY): Backend connection. Use this for OCC adapter implementations, normalizers, and serializers.
    • assets/: Translations.
    • styles/: Styles.
    • schematics/: Installation schematics.
    • <lib>.module.ts: The main module that bundles core, components, and occ to enable lazy loading.