Experience Fragments
Purpose: Reuse designed, authored blocks across pages and channels, and know how XFs differ from synthetic includes.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | Reusable composed blocks |
What an XF is
A mini-page (/content/experience-fragments/…) built with normal components, embedded into real pages by reference. Edits to the XF appear everywhere it is used — one authored source, many placements.
| Property | Behaviour |
|---|---|
| Structure | A page-like tree with its own template |
| Variations | One XF can hold web/channel variations sharing content |
| Embedding | Core "Experience Fragment" component on pages |
| Publishing | XF must be published like a page; embedding pages reference it live |
XF vs alternatives
| Need | Use |
|---|---|
| Same designed block on many pages, authored once | XF |
| Same *data* in many renderings | Content Fragment |
| Same component defaults everywhere | Template initial content / policies |
| Shared header/footer | Template structure (locked), not XF — unless authors must edit it |
PHI example
The "Why choose PHI gold cover" band (icon trio + claims + CTA) appears on every plan page and in campaign landing pages. As an XF: marketing edits it once; publishing it updates all plan pages after dispatcher invalidation.
Engineering notes
- Cache consequence: an XF edit invalidates *the XF's path*, but embedding pages' cached HTML contains the rendered XF — invalidation must flush embedding pages too (statfileslevel design, or resfresh strategies; see Dispatcher anatomy).
- Components inside XFs must not assume the containing page's context (currentPage is the XF page during XF editing).
- Keep XF templates minimal — a layout container and approved components.