In instances where a single page accommodates multiple binding contexts due to modular systems employing bindable elements, a challenge emerges. The aim might be to display content from a specific context, yet not within the same UI as the context, but in a distinct screen area. To achieve this, it’s crucial to segment the UI, ensuring the shared context’s UI isn’t confined to the component’s DOM.

Additionally, it’s important to acknowledge that bindable elements, when parsing their UI, rely on their DOM structure, initiating from the component’s root and processing its offspring recursively. If the UI is relocated from this context, it won’t be parsed, consequently not activated during the binding process.

A potential solution entails designing a UI devoid of its own context but inherits the context from an existing element. While it possesses its own UI and parses it, this occurs in harmony with the provided context, ensuring seamless integration and functionality.

Widgets provide a solution to this issue. They lack an inherent context; instead, both the context and UI markup are transmitted to the widget via a messaging system.

Widgets address this challenge by not having their own context; rather, they receive both the context and UI markup through a messaging system.

In the scenario of crs-binding, a convention exists for targeted events utilizing postMessage, functioning similarly to event aggregation but in a more focused manner. The practice here is to feature a method on the element named “onMessage,” where parameters are dispatched, enabling the component to respond accordingly.

crs-binding incorporates a custom element known as crs-widget, which features a public method onMessage with a singular args parameter. There are a couple of essential items to provide to any instance of crs-widget, namely:

1. Context ID
2. HTML

The HTML can be supplied through either of two properties on the args:

1. url – specifying the file location of the markup to be loaded
2. html – a string representation of the HTML to utilize

In case both html and url properties are set, the html property will take precedence.

Upon invoking onMessage, the prior content of the crs-widget instance is discarded and the bindings for that UI are cleared. Following this, the new UI is loaded, analyzed, and the binding resources are initialized for usage. Throughout this procedure, the widget’s data-ready attribute is toggled to false, and is reverted back to true once the component concludes loading.

Adhering to the eventing convention, crs-widget enables message dispatch from any part of the system to that element via the postMessage feature. Additionally, if you possess a handle to that element, you have the option to call it directly within the code.

const url = new URL("./widget.html", import.meta.url);
const context = this.bid;

await this.widget.onMessage({ context, url });