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?
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Hi @Jon_Maguire,
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.
Hi @Jon_Maguire,
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.
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?
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies