Uncertainty on How to Use Experience Fragments on an Angular Site | Community
Skip to main content
JonMaguire
JonMaguire
Level 3
September 9, 2025
Solved

Uncertainty on How to Use Experience Fragments on an Angular Site

  • September 9, 2025
  • 1 reply
  • 1177 views

I’m trying to understand experience fragments and how I can use them on our customer portal site. Our content authors would like the ability to build them in our main site authoring environment that is on AEMaaCS. The portal site is Ionic/Angular and has different CSS and JS than our AEM site.

Where I’m having difficulty is understanding how the clientlibs of our main site can be used. Is this something that needs to be handled by the link rewriter for experience fragments based on a specific experience fragment template so that the correct domain is used? Something like what is discussed on this page about Target offers? Or am I overthinking this?

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/configuring-and-extending/experience-fragments#default-link-rewriting

Best answer by SantoshSai

Hi @jonmaguire,

You don’t need to bring your full AEM site clientlibs into the portal. Experience Fragments (XFs) are meant to be consumed as content, not as a way to load page-level CSS/JS.

Best practice is:

  • Author portal-friendly XF variants that don’t rely on your global clientlibs. Keep them lightweight and self-contained.

  • Consume them in the portal either via .plain.html (to inject authored markup) or .model.json (if you want to render with Angular components and apply your own styles).

  • AEM’s default link rewriting ensures that URLs in .plain.html are rewritten to absolute publish-domain links. This is the same mechanism used when delivering XFs to Target. You only need a custom ExperienceFragmentLinkRewriterProvider if you have special routing rules.

 

1 reply

SantoshSai
Community Advisor
SantoshSaiCommunity AdvisorAccepted solution
Community Advisor
September 9, 2025

Hi @jonmaguire,

You don’t need to bring your full AEM site clientlibs into the portal. Experience Fragments (XFs) are meant to be consumed as content, not as a way to load page-level CSS/JS.

Best practice is:

  • Author portal-friendly XF variants that don’t rely on your global clientlibs. Keep them lightweight and self-contained.

  • Consume them in the portal either via .plain.html (to inject authored markup) or .model.json (if you want to render with Angular components and apply your own styles).

  • AEM’s default link rewriting ensures that URLs in .plain.html are rewritten to absolute publish-domain links. This is the same mechanism used when delivering XFs to Target. You only need a custom ExperienceFragmentLinkRewriterProvider if you have special routing rules.

 

Santosh Sai
    JonMaguire
    JonMaguireAuthor
    Level 3
    September 9, 2025

    Thanks, @santoshsai 

    For your first bullet point, is it expected that an author will not see the full end result as far as styling, etc. when building the experience fragment in the AEM authoring environment? Is that what you mean by lightweight? The styles will be handled by the portal site?

    SantoshSai
    Community Advisor
    SantoshSaiCommunity Advisor
    Community Advisor
    September 9, 2025

    Yes, that’s correct. When you build an Experience Fragment in AEM for use in an external app (like your Ionic/Angular portal), authors will usually only see a basic styled version in the AEM editor. The “lightweight” part means the XF shouldn’t depend on your site’s global clientlibs - instead, the portal’s own CSS/JS will apply the final look and behavior once it’s consumed.

    If you want to make it easier for authors, you can add minimal/neutral styles in the XF template so they can see structure while editing, but the true end result comes from the portal.

    Santosh Sai
      Terms & ConditionsAccessibility statement

      Loading footer...