Decouple React SDK Bridge from React SDK Components

[wimbarelds]

Is your feature request related to a problem? Please describe.

Due to the components and bridge being tightly coupled, it is not possible to use either one without the other.

If we wish to use the bridge, but not use the reference set of DX components, all we can do is create our own components (However, all of the reference components from react-sdk-components would still be loaded due to the current tight coupling).

Similarly, if we want to build our own bridge from Constellation JS to a component library that uses (parts of) SDK Components (whether termporarily or permanently), this would be impossible. Since many of the components from react-sdk-components import getComponentsFromMap, createPConnectComponent and StoreContext from the bridge directory (making them incompatible with any other bridge).

Describe the solution you'd like

Decouple React-SDK-Components from React-SDK-Bridge using React Context Providers instead of direct imports.

For example:

import createPConnectComponent from '../bridge/react_pconnect';

becomes:

import { BridgeContext } from '@pega/react-sdk-bridge';

function TheComponent() {
  const { createPConnectComponent } = useContext(BridgeContext);
  // rest of component
}

This does leave the question, in which library should the PegaSdkComponentMap file be placed? Since the reference implementation of the bridge would likely want to use this. I think the easiest way to resolve this would be to add this map as an argument to the createPConnectComponent function or component, or to provide it as a Context value.

A nice benefit of this solution is also that it allows you to provide a different set of components for a different context (for example, maybe using smaller UI components inside a modal).

Describe alternatives you've considered

The only workable alternatives I can imagine are either cloning the package and making our own changes, or making edits in node_modules. Both of these solutions are a bad practice and would be difficult to maintain.

Additional context

I have tried to consider up and downsides of this, and come to the following:

Downsides:

• The new “react-sdk-components” library would still import the BridgeContext from “react-sdk-bridge”.

Though this is unfortunate, it is (IMO) minor. The Context can easily be written such that the actual bridge code/implementation is not included in the imported context object. Alternatively, it would also be an option to abstract React Context objects to a separate library (though that feels excessive to me).

Upsides:

• Much greater flexibility
• Less tight coupling
• More appropriate/less confusing library naming
• Better adherence to React standard practices.
• Ability to release updates for either bridge or components independently.

Further notes: In general I believe a lot of flexibility could be gained from using React's Context Providers more broadly.

If there are any questions or remarks with regards to this request, I would be happy to see them and respond / think along. I think this change would be relatively easy to implement, and this would also effectively resolve #240.