We already have something in common just because you’re reading this post: you love to get the scoop on the newest technology! And if you’re like me, you also compare its capabilities to what you could do in the past. It can be exciting for cool new things, but also alarming if you want something you could once do and don’t immediately understand how to have the same outcome.
If you’re building a net new application on Cosmos React, you might notice that action sets are missing. What’s that all about?
Stay calm. There’s a good reason. First, let’s back up just a bit and set the context.
Reimagining and Re-architecting
We’ve been busy reimagining how users experience software and how developers build software. We’ve also been rearchitecting the underlying technology that drives software.
The outcome is Cosmos React, Pega’s new OOTB UX design system and front-end, which offers a cohesive UX library to optimize business workflows and outcomes. Under the hood, Cosmos React is a single-page application architecture based on ReactJS and a client-side orchestration layer—the fastest we’ve built. Ever.
In this new architecture, how you build applications with Pega shifts from heavily customizing the UI with low-level Section rules and discrete UI controls to quickly configuring a desired business outcome that generates the end-to-end experience.
Let’s dig a bit deeper.
With the section-rule-based UI architecture that you know, you built exact UIs by customizing sections of your application from the ground up, dragging and dropping various controls, such as buttons and dynamic layouts.
With Cosmos React, you configure your application, which generates a largely prescriptive overall experience. Cosmos React generates the end-to-end experience, including the UI and its plumbing to events and data, for you. In this app dev paradigm, you don’t need action sets.
Action sets were extremely flexible and heavily used. So, it’s understandable that, as a Pega developer, you might think at first that being unable to configure an action set on specific UI controls is a feature limitation. But there’s a reason for this—to simplify your life as a Pega developer, as well as the lives of designers and users.
How exactly? It has to do with something that comes long before we Pega developers flex our tech muscles and take out our buttons and action sets. It’s about patterns.
Look at it this way: Let’s say I borrow your car. I have no idea what type of car you drive, and I probably won’t ask because I’m fairly certain I will know how to open the door and trunk, put it in drive and reverse, make it go and stop, and steer it. Cars have common patterns. So does case management.
For instance, a typical case management pattern in a typical customer service call case might be to search for and select a customer data record to associate with a service case. Let’s refer to this pattern as “Search and select.”
What do patterns have to do with action sets?
Traditionally, you might build this search and select pattern by using an action set combined with other UI controls, likely playing with an overwhelming number of UI control property panels along the way, for example:
- Create a Section rule to hold the search form and results table.
- Assemble a search form with dynamic layout and various form controls.
- Create server-side logic to perform the search.
- Create a Search button, and then create an action set to call server-side logic to search.
- Create a table to hold the search results.
- Configure its data source and columns.
- Add a column to hold a radio button for selection.
Watch the sped-up process of building a search and select pattern with an action set below.
Right. So, what's the big deal?
In addition to the MANY steps developers must take to build an action, it can also be built in many ways.
In addition to duplicated efforts and extra code and rule maintenance, the main problem here is the inconsistency in the UX, which creates usability problems. For example, think about your favorite suite for word processing, presentations, and spreadsheets. What if you had to open a file in a different way in each application? Users must discover and learn how to open a file in all three apps. Also, the developers must write and maintain code for three different implementations.
One goal of a design system is to provide consistency to help users know what to expect. Regardless of which of those apps you use, the overall experience in all of them is the same. Why? They’re all built with the same design system.
Consistent user experience is a major reason why defining highly customized action sets on a control is not part of the development paradigm in Cosmos React. In Cosmos React, the goal is to offer typical patterns as a configuration option in the model, and then generate a consistent front-end experience across the application stack.
What about my existing applications?
This post demonstrates a configuration approach in the context of a new application only. Watch for more information in the future with guidance on migrating existing applications, including their action set configurations.
How does the configuration approach work?
Using this configuration approach, in minutes—literally—I can configure this search and select pattern, end to end. As the following video illustrates, using App Studio, I configure a Data Reference field type in my case data model. Next, I configure the View to use the Data Reference, and then I enable search on two fields in the data model.
No duplicated code exists, and the “search and select” experience is consistent throughout the application stack.
You’ve captured every single action set pattern that I’ve ever built and made it available OOTB?
Obviously, we cannot capture every pattern that has ever been built or that could be conceived and make it a configuration in the model. A developer might have used action sets in an infinite number of ways.
Moving forward, our goal is to capture high-value, typical patterns that clients need for case management applications and offer them as a configuration in App Studio. This means faster building, consistent experiences, fewer logic bugs, less rule maintenance, and more upgrade-proof applications.
I have an advanced, highly customized use case that I can achieve with action sets, what do I do in Cosmos React?
No problem! I know where you’re coming from. My extended background includes enterprise development, specializing in low-code tooling. Every project had an advanced use case requiring something highly customized. That is where a Custom DX Component, an extension point to Cosmos React, comes in handy.
In advanced use cases, a custom DX component allows professional front-end developers knowledgeable in ReactJS/JavaScript/HTML to assemble, through code, the core Cosmos components, such as a button, to build something new. Providing quicker time to value, our command line interface (CLI) tooling scaffolds your custom component and publishes it back to the server where it can then be used in View authoring in App Studio.
For example, a customer has a unique pattern whereby they must integrate with a private JavaScript API to capture fingerprints from a device connected to their computer, and then copy the scanned fingerprint to an image field in the case. In Section-based UI architecture, the customer built this function using an action set that calls a Run Script, etc. In Cosmos React, they might build this as a custom DX component.
Remember that we’ll be using the existing UI architecture with section rules, skin rules, and action sets for years to come. When we need heavy customization with action sets, using Pega’s classic, section-based UI architecture remains an option.
You keep emphasizing “configure,” “configuration,” and “outcomes.”
Yes! Configure. Configuration. Outcome. They are the trifecta of words to take with you after reading this article. If you’re still with me, these words should conjure all kinds of advantages!
Why? Using the configuration approach fundamentally produces the same outcome as using action sets in the classic UI architecture would have. However, configuring is faster, more consistent, and easier. The difference? Your clients will get more value out of UX and get it faster. Your users will learn the software more easily. Ultimately, everyone involved will have fewer complex processes. Providing flexibility for advanced use cases, you can also build a custom DX component to extend Cosmos.
And when you, as the Pega developer, can provide value faster, you build something in a fraction of the time it used to take.
Go, you! You’ve got this!! Now go make something great!
Ideas? Stuck and need help? My colleagues and I are happy to work with you in the Pega Collaboration Center. Post a question. See you there!
Related Resources
- Learn to configure Cosmos React.
- Learn to configure Theme Cosmos on the classic section-based architecture.
- Check out Cosmos React components in action.
Don't Forget
- JOIN THE CONVERSATION on Collaboration Center
- FOLLOW @PegaDeveloper on Twitter