Skip to main content
Version: next

Features

Since version 3.9

To learn more about extension features, you can read the Extension Features reference docs.

accountInformation​

Extendable feature for the Account Information page. theme/pages/Account/Information

ui.componentsMap​

  • DeleteAccount: The component to display the delete account component in the account information page

    editorialToolboxSections​

Extendable feature for the Editorial Toolbox component. See theme/components/molecules/EditorialToolbox/EditorialToolbox. This is used to add additional sections to the Editorial Toolbox.

ui.componentsMap​

Components registered in this extension point will be rendered as additional sections in the Editorial Toolbox. Each component should implement its own section structure and functionality.

orderDetails​

Since version 3.19

Renamed in 3.20

This feature was previously named OrderDetails. It was renamed to orderDetails in 3.20 to follow the camelCase naming convention for feature names. Run the 3.20.0 codemod to update your codebase automatically.

Extendable feature for the Order Details page. This feature uses co-located GraphQL fragments — components registered in this feature can declare their data requirements directly.

ui.componentsMap​

  • OrderItems: The component to display the list of items in an order. Comes with a co-located OrderItemsFragment on the Order type. Constrained to targetGraphQLType: "Order".

Facets​

Extendable feature for the LayerFacets component. See theme/modules/Layer/LayerFacets/LayerFacets. This is used to easily customize the components used to render facets filters.

ui.componentsMap​

maps​

Extendable feature for the Map and Marker components. See PostalAddressSelector

ui.componentsMap​

shippingMethodAdditionalData​

Extendable feature for the AdditionalShippingInformation component. See getAddtionalDataComponent.

ui.componentsMap​

The registered component name should be the same as the shippingMethod.method_type value provided in the schema's ShippingMethod object.

recommendations​

Since version 3.13

Extendable feature for product recommendations throughout the application. This feature provides extension points for displaying recommended products in various contexts such as product pages, cart, and homepage.

ui.componentsMap​

  • ProductPageUpsells: Component for displaying upsell recommendations on product pages
  • ProductPageRelated: Component for displaying related product recommendations on product pages
  • HomePage: Component for displaying recommendations on the homepage. Currently set to null by default, allowing extensions to provide their own implementation
  • ProductAddedPopInCrosssells: Component for displaying cross-sell recommendations in the "Product Added" pop-in modal
  • CartPage: Component for displaying recommendations on the cart page
  • CategoryPage: Renders recommendations on the category page

pageSkeletons​

Since version 3.22

Extendable feature for page skeletons displayed during SPA navigations. See PageSkeletonOutlet.

Strict opt-in: the theme ships no active declaration. A page displays a skeleton only when a declaration names it — until then, navigations keep the current behaviour (the previous page stays visible with NProgress). The registry below is a library of skeleton components: it enables nothing by itself. Three declaration surfaces turn a key on:

  1. a route's handle.skeleton (createHandle({ dynamicRoute: {...}, skeleton: "product" })) — the destination route declares its own skeleton;
  2. a link's navigation state (<Link state={{ skeleton: "product" }}>) — the link author knows the destination's page type ahead of time;
  3. a pathname key in the registry itself ("/cart"), registered by any extension — static routes have no handle to declare through, so their declaration lives here. In your own extension:
hooks.registerFeature("pageSkeletons", {
  ui: {
    componentsMap: {
      "/cart": new URL("./theme/pages/CartSkeleton", import.meta.url),
    },
  },
});

Surfaces 1 and 2 activate independently, each covering its own window of a dynamic navigation: the link's state covers the loading phase (while the data fetches — it is the only one that can, since the destination route is unresolved yet), the route's handle covers the post-commit window (the route module still loading). Either one alone displays a skeleton in its own window; declaring both covers the whole navigation. The state's key is not checked against the route's own type: a link declaring category towards a product route displays the category skeleton during loading (the route's own declared skeleton takes over after the commit) — classify links carefully.

ui.componentsMap​

Each key maps a page family to its skeleton component — cart, product, category, cms, generic, plus any key an extension or connector registers. generic is not a fallback: it is displayed only when explicitly declared.

Set a key to null to disable its skeleton. Extensions and connectors can register their own keys — e.g. a brand skeleton for marketplace routes — by augmenting this feature in onFeaturesInit:

// in the extension's lifecycle hooks
hooks.registerFeature("pageSkeletons", {
  ui: {
    componentsMap: {
      brand: new URL("./theme/pages/Brand/BrandPageSkeleton", import.meta.url),
    },
  },
});

Type the new key through module augmentation of @front-commerce/types (see theme-chocolatine/src/types/extension-features.d.ts for the pattern). Declaring a skeleton loads its component (and the SCSS of the page classes it renders) eagerly in the shared layout chunk — the skeleton must be styled before the target route module loads.

Skeleton resolution during the loading phase​

For an in-flight navigation, the skeleton is resolved in two steps (the pathname declaration wins over the link's state — the route's own declaration is more specific than whatever a link guessed):

  1. the destination pathname declared in the registry (e.g. "/cart" — the route's own declaration wins);
  2. the skeleton key declared in the navigation state — the link's author knew the destination's page type ahead of time and passed <Link state={{ skeleton: "product" }}>: React Router exposes it in navigation.location.state synchronously, so the typed skeleton renders on the very first loading frame, with no request and no hover needed (mobile taps included).

Anything else — dynamic destinations without a declared key included — keeps the historical behaviour (no skeleton, previous page + NProgress). A declared key that resolves to nothing (unregistered or disabled) also shows nothing: the declaration promises a specific skeleton, and generic is displayed only through an explicit declaration. Once the data commits on a dynamic route, the route's handle.skeleton key selects the typed skeleton while the route module loads; without it, the historical spinner applies.

A dynamic URL already visited in the session (aliased in the client manifest) displays no skeleton at all — its module is already loaded, there is no loading window to cover.

Annotate the links whose destination type you know statically (product grids, search results, cart lines, wishlists…); leave variable destinations (breadcrumbs, mixed menus) unannotated — a wrong declaration would be worse than none, since it promises a specific skeleton.

messageAuthorRoleBadge​

Since version 3.22

Extendable feature for the badge that displays a message author's role. By default the base theme renders nothing (the placeholder returns null); a backend package provides a concrete badge. gezy-marketplace renders a colored badge for each marketplace role (customer, merchant, operator), fed by the role field of the shared FcMessageAuthor GraphQL interface — so it works for both conversation and dispute message authors.

A consuming component renders it through useExtensionComponentMap("messageAuthorRoleBadge", { MessageAuthorRoleBadge }).

ui.componentsMap​

  • MessageAuthorRoleBadge: The component used to display a message author's role. Defaults to a no-op placeholder in the base theme; override it (as gezy-marketplace does) to render a role badge.