What is the proxy FA ç ade of the Spartacus UI of the sap e-commerce cloud


Proxy Facades

This feature was introduced in version 3.2.

Agent appearance is a flexible mechanism, which can abstract functions from function modules that can be loaded late. This function can be pulled out and completed for any part of the application, such as components, services, instructions, etc.

In the deferred loading configuration, the facade is defined as a very thin layer, which is just an empty class with some metadata, and the facade dynamically creates a proxy implemented by the facade.

The following figure is an example:

What is the proxy FA ç ade of the Spartacus UI of the sap e-commerce cloud

Once any part of the code accesses any method or property of the proxy appearance, the necessary functions will be loaded and initialized secretly, and the calling proxy will be implemented in practice.

By design, the proxy appearance is completely transparent to delayed loading and eager loading scenarios. For preloaded scenarios, when the code is statically linked, the actual implementation masks the proxy provider and can be accessed directly without any proxy layer.

feature module

Functional modules allow you to encapsulate core business logic with components and load any components as soon as they are requested or some logic is needed. The agent facade uses the function module configuration to understand which function contains the implementation of the facade. Whenever a function’s properties are accessed or a method is called, the function is loaded and initialized in the background.

Defining Proxy Facades

This section describes how to define a proxy in the root entry point.

As mentioned earlier, the proxy facade is a very thin layer consisting of a JavaScript class and some metadata that should be available in the root injector. This lightweight injector can then be used in any preloaded or deferred loading portion of the application.

The following is an example of the useraccountfacade proxy definition, which has a get method and is defined by user_ ACCOUNT_ CORE_ Feature implementation:

  providedIn: 'root',
  useFactory: () =>
      facade: UserAccountFacade,
      methods: ['get'],
export abstract class UserAccountFacade {
  abstract get(): Observable<User | undefined>;

The lightweight facade Module shown above is part of the eager loading package (usually the root entry point, in the case of the default Spartacus Library), and its specific implementation (useraccountservice) is provided in the delayed loading block. The delayed loading block is usually implemented in the core folder of the library.

The following is an implementation example:

What is the proxy FA ç ade of the Spartacus UI of the sap e-commerce cloud

export class UserAccountService implements UserAccountFacade {
  // ...
  get(): Observable<User | undefined> {
    // ...

How to provide implementation for the facade in the lazy loaded chunk:

export const facadeProviders: Provider[] = [
    provide: UserAccountFacade,
    useExisting: UserAccountService,

For convenience, the appearance is provided as both useraccountfacade and useraccountservice. This makes it easier to override (only the useraccountservice implementation must be overridden) and makes it easier to load scenarios, where the useraccountfacade provider overrides the default facade proxy provider.

Implementation details

Facadefactory creates a simple appearance proxy class based on the configuration of methods and properties.

All methods must return observable objects, otherwise they will be ignored.

What is the proxy FA ç ade of the Spartacus UI of the sap e-commerce cloud

Accessing any attribute (must be Observable) or invoking any method triggers the functional module referenced by the appearance agent. After loading the feature, the feature module injector is used to inject outward appearance, which is provided inside the feature module and has the same token as the appearance agent. Then the corresponding attribute or method in the implementation is invoked and transferred to the caller.

You can also use the async flag set to true to create a skin factory. This facade will briefly delay the call to the facade implementation after the initialization of the functional module, which allows asynchronous facade initialization. This is the recommended setting when the facade uses asynchronous initialized ngrx storage.

Default Approach in Spartacus

In Spartacus, appearance agents are defined by default in the root entry point, which means that they are statically linked to the main package. Therefore, with minimal overhead, any component or service can inject its lightweight proxy token without knowing whether the facade is part of any deferred loading or preloading function.

Typically, a facade defines a reference feature_ name_ Core features, while by default, features are provided in the feature_ Name feature, and feature_ name_ Core as feature_ Alias for name. With this design, the facade agent works in the default configuration, where the core, OCC, and component modules are bundled into a deferred load module. On the other hand, it is easy to split this module and load only the core part (without components) to achieve fine-grained delayed loading. This can be done by defining configuration and delayed import for feature_name_core function.

Later, I will illustrate it with some specific examples.

More Jerry’s original articles are: “Wang Zixi”:
What is the proxy FA ç ade of the Spartacus UI of the sap e-commerce cloud