Hello Team,
I have a question regarding custom React-based DX API Components in Pega Constellation.
Recently, I developed a custom Landing Page component (example: MyLandingPage) where the table header was initially displayed as “Customer List”. Later, I changed the label in the React code to “Customer”.
My understanding is that for every small UI label modification, rebuilding and republishing the component package may be required for the changes to reflect in Pega.
From a development perspective, this becomes slightly challenging during active requirement discussions with clients. For example:
• Client requests a label change
• Developer updates the React code
• Again rebuilds and republishes the component
• Later client requests another small text/UI change
In traditional Pega UI configurations, such label changes can usually be completed within a minute directly from the UI/rule configuration layer. However, for custom DX Components, repeated republishing may consume additional development and deployment time.
My questions are:
-
Is republishing mandatory even for small UI text/label updates in custom DX API Components?
-
Is there any development mode, local server setup, hot reload capability, or alternative approach where we can see minor UI changes immediately without republishing every time?
-
What is the recommended best practice followed by teams working extensively with custom Constellation React components?
Would appreciate guidance from experts who have worked with custom DX Components and Constellation-based UI development.
Thank you.
Hello @VijayG17537995
When you are dealing with custom DX components, you need to consider multiple factors that affect the development practices. Yes, republishing is needed and to my best knowledge there is no alternative for that.
If you do not have any OOTB facility available then you can go for custom components. But if it involves multiple editable fields which can be achieved with OOTB views, then refrain from using custom components.
Custom components are meant only to handle specific, complex scenarios which cannot be achieved using OOTB components. Focus on the business outcome rather thinking about the UI elements. There are multiple alternatives for most of the scenarios which you can approach. Refer to the Constellation 101 series for more details.
If you are still going with a component, then ensure that you take care of below things,
- Parameterize the component as much as possible. Labels, Data page names, Property references, Flags, etc can be passed an input parameters so that you need not modify the component frequently and can still control the behaviour.
- Ensure that you take care of the accessibility and UI guidelines.
- Take good care of the performance w.r.t refreshes, server hits using DX API’s ,etc
- Security is the highest priority.
- Make the component as small and modular as possible so that you can re-use it throughout your application.
- Ensure that you select correct component type depending on whether you are using it in a landing page or on a case context. If landing page, go for widget type and for case context, go for template or field type.
- Ensure that you have proper documentation for the component so that people are aware of the usage and importance of the component.
Hope this clarifies your queries. Feel free to let us know your scenario where you went for custom component and we can suggest OOTB alternatives if any.
Regards
JC
I understand the pain. This is not ideal Developer Experience. That is why I suggest using Development Mode. Take a look here to find info on how to enable it Local development for Constellation DX components
Reiterating @JayachandraSiddipeta’s point 1.
Consider the design time of your component just as much as the run time.
If you foresee or plan for something to change, it should be configurable in App/Dev Studio when using that component. This would save you having to recreate it for reasonable changes.
Example of configuration in a DX Component
This is one of the tips @oveni and @Josh_Helmbrecht shared in Webinar Replay! Extending Constellation: A Deep Dive into Constellation DX Components.
@VijayG17537995 you posted this as “user experience knowledge share”, given this is question it is best suited as “user experience”. I have moved it to that category.
This will now give you the ability to mark a reply as “solves problem”, which will help others who may come across this in the future (by promoting that reply). It also gives some extra points/credit to the person with correct answer for the Leaderboard, so a nice thing to thank them.
