It's common for teams to need to share component layouts between multiple compositions. Patterns let you do this by defining a pattern composition that can then be referenced by other compositions anywhere that the pattern's component type is enabled.
For example, you could use a pattern to share a legal disclaimer, an author bio, or standard global header across many compositions. Technical or content architects may employ patterns as they plan out content structures for a project.
Configure a pattern#
Create a pattern and configure it at the component level.
There are two ways to create a pattern:
Navigate to the component on which you want to base the pattern, select the Patterns tab, and click the Add pattern button.
Navigate to the component in an existing composition you wish to convert into a pattern. Select or add the component, and click the ••• either in the structure panel or the property panel.
About this step
For this to work, the component you're converting, and any child components, can't have a connection to a composition data resource.
You can use a pattern like a regular component by adding it to a composition in a slot. If patterns are available they will appear when you insert a component into a composition in the add to slot list.
Change a pattern#
When you reference a pattern on a composition, you see the pattern's details but they can't be edited. This is to prevent inadvertently editing shared component data.
To edit a pattern, which will change it everywhere it's referenced, you can:
- Click the ••• menu on a referenced pattern in a composition and choose Edit Pattern to open the pattern for editing.
- Find the component and view the "Patterns" tab. Select the pattern and open it for editing.
Sometimes you may wish to 'unlink' from a pattern and make a copy of its contents. This lets you make a copy of the pattern that can be changed without affecting the original pattern; the copy will no longer have any relation to the pattern.
To do this from the composition editor, click a referenced pattern's ••• menu and choose Unlink Pattern. The copy will expand in place.
Patterns with pre-connected data#
Patterns can connect to external data. When you're working with data types and data resources, it's best to leverage patterns to keep the authoring experience smooth.
There are two basic strategies for handling external data when building a pattern:
- You can permit authors to override or replace connected data each time the pattern is used.
- You can prevent authors from changing the data resources, making the connections static.
Architects can blend these strategies as patterns can connect to more than one data resource.
For patterns using the same data for each implementation, the author only needs to add the component to the composition. All other configuration is stored in the pattern. This is a great strategy for legal copy. Each time an author uses the legal disclaimer pattern, it will reference the same piece of legal copy from the source system.
For editable data connections, configure your pattern using a simple data source. For example, you may create an "author card" pattern where a different author is selected each time it's used. The connected author would be considered the default content for the pattern.
You can override patterns in a few different ways.
- Pattern data resources: Patterns default to allowing data resources to be overridden. To change this, open the Advanced Options accordion on the pattern data resource and deselect “Overridable.” A pattern can have some data resources that are overridable and others that aren't. If you deselect the "Use as default" toggle you must select a data resource each time the pattern is used. Otherwise, the resource chosen during pattern creation will be the default.
- Advantages: Visual preview will show a fully functional component, making it clear how it looks and works in the context of a given digital experience.
- Disadvantages: Defaults can be powerful; and it may be important to force an explicit choice about what data resource to use in a pattern.
- Parameters: Parameters can be marked as overridable. Doing so allows their value to be changed on parameter instances. This includes replacing the value with a different data resource or from a different data type.
- Slots: Slots and their contents aren't overridable. All components in all slots will be present for each pattern instance
There are some limitations of where and how you can use patterns that you should be aware of.
- Creating a pattern from a component type, such as Personalization, Localization, or A/B Test, which inherits its allowed components from a parent slot isn't possible. This is because you can't determine the components allowed in the pattern with no parent slot.
- You can't reference a pattern as the root component of a composition
Care must also be taken when deleting patterns. If you delete a pattern that's being used across several compositions, you could inadvertently delete an experience that will affect your site. An error will be shown on the composition where the pattern can no longer be found.
Draft and published states in patterns#
When editing patterns and compositions it's important to be clear at how they will behave in different states. Here's how compositions are fetched in draft or published compositions and patterns.
|Fetch composition (draft)||Fetch composition (published)|
|Draft pattern & draft composition||Returns both in draft state||Returns a 404|
|Draft pattern & published composition||Returns both in latest draft state||Returns composition but “pattern not found” error for pattern|
|Published pattern & published composition||Returns both in latest draft state||Returns both in published state|
|Changed pattern & published composition||Returns both in latest draft state||Returns composition in published state, pattern in last published state|