Get Started with Sample Pages and Component Types

Learning Objectives

After completing this unit, you’ll be able to:

• Identify the page type and component type ID naming convention.
  
• Explain how page types relate to component types.
  
• Describe the purpose of mock attributes.
  
• Explain how resolved values relate to the B2C Commerce API.
  
• Describe how to update Page Designer elements in cache.
  

Explore SFRA Sample Cartridges

You’ve installed, configured, and uploaded your Page Designer files to the server. Before you build your own custom cartridge, take some time to explore the sample Page Designer page and component types that come with SFRA.

Start with the two SFRA sample cartridges.

• app_storefront_base: The page and component types including storefront runtime files. Developers use these templates, JSON, and scripts in the storefront site’s cartridge path.
  
• bm_app_storefront_base: SFRA reference implementation of a Business Manager cartridge for Page Designer UI artifacts. The implementation includes design-time files like names, descriptions, icons, and custom attribute editors. In your own implementation, you create a custom cartridge for these assets and add it to the Business Manager site’s cartridge path.
  

Learn the ID Naming Convention

The ID is the key to accessing page types, component types, and custom attribute editors in your code.

A page type, component type, or custom attribute editor ID is a combination of the subdirectory (if any) that includes the meta definition file and script file, in addition to the file name without the extension. Separate the levels of the subdirectory and the file name with periods.

For example, a page type named homepage with its files located directly under cartridge/experience/pages gets the ID homepage. Put those same files in a subdirectory storefront/campaigns and the ID becomes storefront.campaigns.homepage.

This table shows how file location maps to ID.

When you save page types and component types to the database, their IDs get the prefix page. or component.; that prefix plus the ID has a 256-character limit. If you exceed the limit, an error occurs. You can move files to a higher directory level to shorten the ID.

Explore Page Types

Page types define the overall structure of a Page Designer page. SFRA includes page types that define regions where merchandisers can place components. A page type meta definition file describes the regions on the page where you can place components.

SFRA provides page types for standard storefront pages and dynamic page types for Product List and Product Detail pages. Dynamic page types support aspect types that define required attributes for runtime context, like displaying the category or a product.

Get to Know Component Types

Component types contain attributes that merchandisers fill in to make pages engaging. When you develop component types, you define attributes that merchandisers configure. A carousel component type, for example, gives the merchandiser control over the number of slides that show per device type.

SFRA provides prebuilt component types organized into groups.

• Commerce assets: Product tiles, category tiles, and banners that show product and category information. Dynamic Banner uses data binding to show category-specific images and text.
  
• Commerce layouts: Layout components that structure other components, such as grid layouts, carousels, and Product Listing Layout.
  
• Content: Static content components like images, text blocks, and the Image With Text component.
  

Let’s take a moment to examine three components closely.

• Main Banner: Shows a hero image with a text overlay and a category picker that creates the link.
  
• Carousel: Shows product tiles or other components with configurable display attributes for phone, tablet, and desktop.
  
• Dynamic Banner: Shows banner images and text configured in Business Manager for a category. Uses dynamic attributes with dynamic_lookup properties to bind component data to the page’s category context.
  

Each page type and component type has a meta definition file and a script file.

Configure Component Attributes

You build component types around attributes. Each attribute in a component type’s meta definition file has a type, and that type determines how the merchandiser sets its value in Page Designer.

This table describes common attribute types and their UI controls in the Page Designer visual editor.

If none of the standard attribute types fit what you’re building, create a custom attribute editor. A later unit explains that process.

Understand Resolved Values

Page Designer stores content attributes in a map—called the content dictionary or context object—with attribute IDs as keys and resolved values as values.

A resolved value is a value converted to a B2C Commerce API object. For example, an attribute of type product stores a product SKU as its raw value. Page Designer converts that SKU into a dw.catalog.Product object, so your script works with a fully usable API object rather than a plain string. Some attributes don’t require conversion.

This table shows how content attribute types map to their B2C Commerce API objects.

Recognize Mock Component Placeholders

When a merchandiser drags a component onto a Page Designer page in edit mode, a mock component placeholder appears until the merchandiser configures the component attributes. Mock component placeholders also appear when a merchandiser creates a localized page based on another page, or when a page doesn’t render because it’s missing attributes.

The mock placeholder signals that the component lacks configuration or contains an error. The merchandiser moves the mock component and edits it just like a regular component. Mock components show only in edit mode.

A mock component draws its display from the name of the component type as configured in its meta definition file. The thumbnail image comes from a custom cartridge for Page Designer UI artifacts.

The HTML wrapper is always div. Mock components use two classes: sfdc-component-mock and sfdc-component-{typeID}-mock, where {typeID} is the ID of the component type. Component type ID values include dots. When used in the class name, replace the dot with a hyphen.

To customize how a mock component placeholder displays, apply custom CSS to the mock component class.

Manage Caching for Page and Component Types

B2C Commerce caches page types, component types, and custom attribute editors in memory at intervals that vary by environment.

To refresh page types, component types, and custom attribute editors on a production environment or to refresh them immediately on other environments, perform a code version switch. After you develop or modify Page Designer elements and replicate them to production, you issue an event for a code version switch and the elements refresh immediately.

Up Next

In this unit, you discovered how page types, component types, and attributes relate. And you learned the ID naming convention. You explored SFRA prebuilt component types including components that use dynamic attributes for data binding. You also learned how mock component placeholders work, how resolved values map to B2C Commerce API objects, and how Page Designer elements update in cache.

In the next unit, you take a closer look at the underlying code files that make page and component types work.

Resources

• Salesforce Help: Replication in B2C Commerce
• Salesforce Developers: Component Attribute Types and UI Controls
• Salesforce Developers: Component Attribute Types and Resolved Value Objects