Lately, I was exploring Pega’s React SDK, and a question came up:
I take it that clients with specific styling requirements usually utilize the override-sdk to render Pega in their own design and component system (they take the Material UI overrides as a starting point and exchange it with their own system).
However, if I understand this correctly, as your own React components might offer specific configuration options/props, you’d always only implement the shared subset between, say, the Pega dropdown as it can be configured inside Pega and the display component (maybe your component allows for multiple option selection, but the Pega dropdown doesn’t, just as a random example).
How do clients usually deal with this? Do they create custom components /utilize the custom-sdk for that? Or is this an approach that is rarely seen among clients and they just implement the subset of configuration options?
This is not a post about the fact that you shouldn’t utilize the SDK if it isn’t absolutely necessary. I know that this is a decision with consequences and would love to focus solely on my question. Thank you so much already!
Hi @Franz_H , I’m sorry I don’t quite follow your question? Is it a question of how much you customize in the SDK vs keep from OOTB?
If so, then it depends on the scenario. If its only a few styling/interaction patterns then a few Custom DX components might be enough, if its a full design system then SDK with lots of Custom DX Components and portal styling would be needed.
Either option, you can configure the Design Time configurations of the components you use and the Run Time elements. So you could add new configurations to the components OR just make your own drop down with say the same configuration options, just different run time.
Does that make sense? Or have I missed the point of your question? (apologies, i’ve been on PTO for 3 weeks, so my brain is just getting back into gear)
thank you so much for responding, much appreciated! Hope you had a great time off.
Let me try to clarify what I meant:
When using the override command for a component in the React SDK, you’re initially swapping out the Constellation components with MUI components; then, based on the provided mapping (DX API to rendered output), you can replace the MUI component with your own. The key constraint here is that the design-time configuration options inside Pega stay exactly the same - you’re only changing what renders at runtime.
For most components, this approach would probably be perfectly fine and effective. However, what happens when one of your own design system’s components exposes capabilities that the Pega design-time model simply doesn’t account for?
If you want to fully utilize the power of your own design system, I assume you’d use the overrides for the bulk of the component library (because of the ease), but then drop down to a custom DX component specifically for the dropdown (or whichever components have that mismatch) - essentially mixing both approaches. Is this correct and how clients handle such a scenario usually in practice?
very interesting question. One solution is to create custom DX Component that accept props that matches your design system extended list of props. Yes, you can create custom components in SDK.
I have couple of ideas how you can extend list of props without the need to have custom dx component but please let me validate it and come back to you.
In fact, I would say this is preferred approach than hard coding the run time experience. The more you make configurable in design time the more flexible your component and configurations will be (aka future proof).
The team run through some examples in our DX Component webinar. We had 2 sessions and two different people present their components, so I would suggest watching both, we provide a full breakdown and recordings on our Summary Post.
Thank you so much @Kamil_Janeczek and @MarcCheong. I will go through the provided resources and will check out editing the config-ext.json. Much appreciated !
!