Skip to main content
Import the supported Widget Worker SDK from one entry point:
Use the generated defineWidget, defineWidgetPackage, and startWidgetPackage references for exact fields, types, and return values.

Define one widget

Keep the widget name stable after publication. Defaults must satisfy the property schema and render a useful initial state.

Define a package

Package ownership changes the required identity fields. Start from the generated project for your package model and use the reference for the exact options.

Widget types

A screen places a widget by its type. A package widget’s type starts with company. or droplet., continues with the package’s identity, and ends with the widget’s name. That keeps it apart from built-in types like TextWidget, which a package can never replace. The portal loads a package only if none of its widget types is already registered. If one is, because two packages share an identity, the portal skips the whole package. It logs a warning in the browser console and shows nothing on the page. Keep each package’s identity unique, and each widget name unique within its package. A screen node whose type no loaded package provides renders nothing. Check that the package is published and available to the portal. See Droplet package visibility.

Start the worker

The generated worker entry starts every registered widget:
Keep values that cross the worker boundary JSON-serializable according to the SDK types. Do not author runtime URLs or generated package descriptors; build and publication own them.