Custom DX Components on Pega 25 -- are we supposed to rebuild everything from scratch?

User Experience
, , ,
1

Hey everyone,

I’ve been building custom DX components on Pega 25 (DX Component Builder v25.1.23) and I hit something I want to sanity check with the community before I assume it’s a gap.

My goal was simple: take the OOTB Text Input, add domain-specific behaviour on top of it, and keep everything the OOTB control already gives authors in App Studio. No overrides, just an extension.

The comparison

When I put the two authoring panels side by side, this is what I see:

Comparision
Comparision1188×797 70.5 KB

The OOTB panel gives authors: Edit mode, Placeholder, Helper text, Field warning with condition and message, Required, Disabled, Visibility.

My custom component gives authors: Label, Placeholder, Visible, Disabled, Required.

Edit mode, Helper text, and the entire Field warning section are missing.
There is also a visual gap in the field list

image
image778×162 27.5 KB

The OOTB control shows a T icon next to the field name in the view canvas. My custom DX component does not. Small thing, but it matters for how authors recognise and trust the component.

My questions

So it seems the expected pattern is to manually re-declare every property from the base control – is that really it on Pega 25?

A few specific things I’m trying to figure out:

The OOTB Field warning section expands when you check the checkbox. I found that the visibility parameter on a GROUP can conditionally show nested fields, so I think I can get close – but I’m not sure about the exact format for the When Rule picker. Is there a WHEN format type in the current SDK, or is there another way to wire that up?

For the type icon – my component already declares "subtype": "Text" and "subtypeLabel": "Text" in the manifest. Is that not enough, or is there something else needed to get the icon to render in the field list?

And more broadly – has anyone found a clean pattern for building on top of an OOTB control without the config drifting every time Pega updates the base component’s authoring contract?

2

In Pega 25, custom DX components do not inherit the full authoring behavior of the OOTB Text Input automatically. The correct solution is to build your custom control as a wrapper and explicitly define every authoring property you want to expose in the component schema, including edit mode, helper text, and the field warning group. For the warning setup, add the When rule as a rule-reference style config field and use group visibility to show the nested warning fields only when needed. The T icon is also not inherited just from subtype, because that display metadata is handled separately by the OOTB control definition. So yes, the practical approach today is to recreate the authoring contract once in your wrapper component and reuse that component consistently.

1 Like