Extending Page Props in the Content SDK

As XM Cloud continues to evolve, many of us who worked with JSS in the past are finding familiar patterns resurfacing — only now they come with cleaner APIs and a much smoother developer experience. One of those changes is how we extend or shape Page Props.

If you built JSS apps before the Content SDK existed, you probably remember implementing your own Sitecore Component Factory. That was the standard way to intercept and enrich layout data before rendering. While it worked, it wasn’t always the most intuitive or elegant solution.

Today, thanks to the Sitecore Client (part of the Content SDK), the process is far simpler and more flexible.

From Component Factory to Sitecore Client

Let’s take a quick look at how things used to work:

• In Sitecore JSS (pre–Content SDK), extending layout data required creating a custom component factory.
• That factory controlled how components were parsed, mapped, and enriched.
• For larger sites, this often meant a lot of boilerplate and custom mapping logic.

With the Content SDK, the Sitecore Client becomes your central integration point — and the need for a component factory disappears.

Instead, you extend the SitecoreClient class itself.

How Extending Page Props Works Now

When you’re migrating from JSS to the Content SDK, the mental model stays similar, but the implementation is far cleaner. All you need is to:

1. Create your own class that extends SitecoreClient
2. Override or add new methods to shape your PageProps
3. Use those custom methods anywhere in your application flow
4. Optionally create reusable plugins to structure your logic (similar to the old props plugin pattern)

This creates a natural place to integrate:

• external data sources
• computed props
• merged fields
• personalization logic
• feature-specific transformations

Here’s a small conceptual example:

import { SitecoreClient } from '@sitecore/content-sdk';

export class CustomSitecoreClient extends SitecoreClient {
async getExtendedPageProps(route: string) {
const base = await this.getPageProps(route);

return {
...base,
customFlags: await this.getFlags(),
marketingData: await this.getMarketingInfo(),
// any additional props you want to attach
};
}

private async getFlags() {
// call your API, do some logic, whatever you need
return { isPreview: false };
}
}

You’re not replacing Sitecore’s pipeline — you’re simply enhancing it.

This Also Plays Nicely With Prop Plugins

If you used props plugins before, the concept translates well. You can organize your extensions as isolated functions or modules, then compose them inside your custom SitecoreClient method.

For example:

const finalProps = await applyPropPlugins(baseProps, [seoPlugin, flagsPlugin]);

This keeps your migration clean while letting you modernize your structure gradually.

Why This Matters

By moving away from component factories and toward a simple class extension pattern:

• Migration becomes dramatically easier
• Page prop customization becomes more readable and testable
• Feature-specific logic stays neatly organized
• You reduce framework-specific boilerplate
• Your codebase is more future-proof as XM Cloud evolves

This is one of those changes where the simplification is genuinely welcome — especially for teams maintaining large, component-heavy solutions.

Thinking Ahead

As XM Cloud continues to standardize its developer APIs, patterns like this one will make customization feel more like extending a modern SDK and less like wiring low-level JSS internals. If you’re currently planning a migration, start by building your own extended SitecoreClient — it gives you a clean foundation to layer future capabilities on.