Workshop offers two features that support embedding another Workshop module: the Embedded Module widget and the Loop section layout ("loop layout").
These features allow building Workshop modules that can be embedded within other Workshop modules. Embedded modules support all features offered by Workshop, though there are some limitations to the interaction of the embedded and embedding modules. This documentation will at times refer to a module that embeds another module as the "parent" module, and the module that is embedded as the "child" module. When this documentation refers to an "embedded module", the reference applies to both the Embedded Module widget, and the module embedded in the Loop layout, unless otherwise indicated.
Embedded modules have a number of use cases, including:
Embedded modules allow a single child module to be configured and reused in many parent modules. Some examples of the types of embedded modules that can be built include:
Embedded modules can be used many times in a single parent module, either through the loop layout, or individual embedded module widgets. Some examples of a child module that would be embedded many times in the same parent module include:
Embedded modules can be used to break up a larger parent module into many child modules for better maintainability. This allows each child module to have its own variable scope, and for each child module to be edited at the same time by different Workshop builders.
An embedded module can be used to provide an area of customization when packaging a Workshop module with Marketplace. The embedded child module will be packaged as a dependency, and at installation time, a Marketplace user may select a module with the same module interface variable type signature to customize part of the installed parent module.
Configuration at the module level for child modules, such as routing, state saving, and auto-refresh, is not used. Should your workflow require, you can configure these at the parent module level, with variables passed down to child modules through the module interface.
Embedded modules do not support the concept of event passing. Event passing would allow a builder to pass an event configuration from the parent module to the child module, allowing the child module to call an event that references configuration from the parent module (for example, the child module calling an event that opens an overlay in the parent module).
A parent module may pass variables backing layout state to module interface variables of the child module as a way for the child to modify the layout state of the parent.
Similar to other "Foundry apps" widgets in Workshop, the provenance of embedded modules used by other Workshop modules is not reported by Data Lineage.
A module may not embed itself, either directly or through a chain of child modules. If a self-reference is configured, the module will display a warning to builders and render nothing to viewers in order to prevent a possible infinite chain of embedded modules. Contact your Palantir representative if you have a use case that requires recursive or self-referential embedded modules.
Embedded modules are separate resources with their own permission settings. If a user has permission to view a parent module that embeds a child module for which they lack permission to view, the user will see a "failed to load module" error.
Embedded modules should have similar performance characteristics to that of normal Workshop modules. One notable difference is that initialization of embedded modules is delayed until the embedded module is displayed in view. Once initialized, the embedded module is expected to run as if the entire module had been configured in the same place.
Note that the child module configuration will be initialized one time per instance, which comes with a cost to initialize its variables, but the child module configuration will only need to be loaded a single time if reused across many instances.
Usage of embedded modules and loop layouts make it much easier for builders to configure very large, complex modules. Builders should be aware of the total number of widgets and variables being displayed at once, particularly ones that are expensive to load.
The Embedded Module widget and Loop layout can only embed other mobile modules when the module is in mobile mode.