pegasystems / react-sdk-components

The React SDK Components repo is used to create the @pega/react-sdk-components and @pega/react-sdk-overrides npm packages used by the Pega Constellation React SDK. These packages provide the initial set of components used by the React SDK to render DX Components with a design system other than Pega Constellation design system.
https://community.pega.com/marketplace/components/react-sdk
Apache License 2.0
2 stars 4 forks source link

Option to allow more than one embed-root per page #241

Open wimbarelds opened 9 months ago

wimbarelds commented 9 months ago

Is your feature request related to a problem? Please describe. The application I am working on embeds Pega views onto a non-pega portal page. One of the things we want to be able to do is have more than 1 embedded view on a pega (For example: a task list and a task-detail), however this appears not to be possible.

Describe the solution you'd like As I understand it, the way the SDK works is generally placing "everything" in a global context. PCore is added as a property of window, and PCore has a single store/context.

Ideally, PCore (and all underlying context/state) would be something we can import as an es-module, and multiple indepdendant instances of it could be created (that all work/manage state/events/requests independant from other instances).

However, that seems like it would mean a potentially huge change spanning more than just this SDK. It might be possible to instead mount a (separate) store to instances of Mashup API (ie: PCore.getMashupApi()). Instances of the component created with createPConnectComponent could be passed an instance of that mashup-api-instance (ie: <PConnectObj {...props} mashupApi={mashupApiInstance} />.

Describe alternatives you've considered

I have tried to consider alternatives, such as the target context, possible with React portals; however that seems like it has a low chance of a working and would introduce complexity and make it llikely for future updates to the SDK to break our 'custom' solution.

Additional context Add any other context or screenshots about the feature request here.

niallriddell commented 9 months ago

Thanks for your suggestions. I'm interested to know why creating a page in Pega and then separating the widgets in that page using a template would not allow you to achieve the same outcome. Assuming that this is not possible, maybe due to design considerations, to answer your original question this is actually a restriction of the Constellation JS engine (for the reasons you mention above). I will create an internal feedback request with this incident as a link, so that their product manager can prioritise accordingly. I will also watch this feedback request and provide updates.

nhe050 commented 9 months ago

Thanks for your response Niall. To explain a bit, we're working on internet facing portals meant for customer engagement, or better, citizen engagement as it focusses on Dutch government. This means we're currently working on creating portals for Dutch government organisations using the constellation architecture using a custom design system. I.e. we're building React portals that suit citizen needs rather than case workers. These portals will support various features in a single view, like a list of assignments, a list of recently added documents in all your cases and a possibility to create a new request (case). Goal is to make this features available through React components that can be orchestrated in, for example, a CMS. That way, we're able to organise the various webpages with any combination of the features available, to suit organisation's needs. And finally, in the slightly longer term, we want to be able to put features like described above from different Pega instances into a single page. For example to have overviews of all your requests with multiple related organisations in a single view in a single portal. Hope this helps clarifying the request. Always happy to discuss further of course. Regards, Niels (CLSA)

wimbarelds commented 9 months ago

Its is as Niels says, but perhaps to visualize this: image

In this image the CMS might be Drupal, Umbraco, Sitecore, Wordpress, or any other website (whether with or without CMS)