Reuse private custom components
Package declarative components, publish immutable private releases, and understand their limits.
Use built-in components and shared composites first. When the catalog does not provide the presentation you need, a portable app can carry private custom components built from a validated declarative HTML-like tree.
These components are advanced app-authoring content. They do not run arbitrary scripts or install a plugin into the platform.
Define a reusable component
A private component has a custom_ type, semantic version, description, property definitions and defaults, declared published values, declared events, capabilities, source tree, and content hash. Its source can use validated tags, attributes, literal styles, nested children, bindings, conditionals, bounded repetition, and slots when the engine supports them.
Map allowed input or click events to the component's declared events and wire those events to normal app actions. A component that emits events must declare trigger capability; declaring an event name alone does not make the runtime dispatch it.
Scripts, raw HTML injection, arbitrary external URLs, and CSS URLs are rejected. A custom presentation cannot use those escape hatches to obtain connection credentials, bypass review decisions, or reach data outside the app's permissions.
Validate and package
Use the downloadable authoring toolkit to validate the component and pack the app. Packing computes the source hash. Change the semantic version when source or metadata changes so a release clearly identifies its content.
Imported component definitions are validated and stored privately before app activation. They remain app/tenant content rather than automatically becoming a platform-wide catalog entry.
Publish privately
The authoring toolkit supports component validation, private publication, and listing private releases. Published private releases are immutable: use a new version for changed content rather than overwriting an existing release. App files can also carry their own component manifests for transfer and validation.
A shared platform catalog component requires a separate reviewed promotion process. Private publication is not public catalog distribution. There is no unrestricted JavaScript extension tier implied by this feature.
Verify compatibility
Portable components require the corresponding engine feature; composite tree constructs require composite support. Check package readiness against the destination before import. Offline preview validates presentation with local fixtures but does not reproduce hosted workflow or connection operations.
See Portable export, Import, and Containers.