CustomScheduledEmailDialogContextDecoratorComponent

Beta API. Mostly stable, but details may change in a minor release, outside SemVer. See API maturity.

Decorates the data the scheduled-email create/edit dialog reads.

The dashboard mounts this component between the connector-provided dialog context and the dialog’s state model, so the value it re-provides is what both the default dialog and the state seeding read — a wholesale ScheduledEmailDialogComponent replacement sees it too. Read the current value with useScheduledEmailDialogContext(), decorate the members to adjust, and re-provide via ScheduledEmailDialogContextProvider:

export type CustomScheduledEmailDialogContextDecoratorComponent = ComponentType<{
    children?: ReactNode;
}>;

Example

function ChannelsDecorator({ children }: { children?: ReactNode }) {
    const ctx = useScheduledEmailDialogContext();
    const notificationChannels = useMyFilteredChannels(ctx.notificationChannels);
    const decorated = useMemo(() => ({ ...ctx, notificationChannels }), [ctx, notificationChannels]);
    return (
        <ScheduledEmailDialogContextProvider value={decorated}>
            {children}
        </ScheduledEmailDialogContextProvider>
    );
}
// <Dashboard ScheduledEmailDialogContextDecoratorComponent={ChannelsDecorator} />

Pass isLoading through untouched. On scheduled email the loading state is on the ordinary path — a widget export renders while its filters load — so a decorator that overrides it corrupts the draft seed on every such open, not in an edge case. Define the decorator outside render, or the dialog remounts (and reseeds) on every parent render.

The contract: change the data, not what it means — every member keeps its documented meaning. The dialog does not check the decorated value; when you override a member, everything that reads it is your responsibility. Spread the value you read ({ ...ctx, member }) so the other members pass through. Wrap functions instead of replacing them. Do not touch members marked as internal machinery.