Stone.js API
    Preparing search index...

    Options for the @Notifications activation.

    interface NotificationsDecoratorOptions {
        announce?: boolean;
        attempts?: number;
        channels?: ChannelConfig[];
        dedupe?: { store?: string; ttl?: number };
        default?: string[];
        dispatch?: "inline" | "queue";
        notices?: NoticeDeclaration[];
        queue?: string;
        recipients?: (id: string) => Promiseable<Recipient>;
        templates?: Record<string, TemplateInput>;
    }

    Hierarchy (View Summary)

    Index
    announce?: boolean

    Whether each delivery is announced on the event bus.

    notification.delivered and notification.failed, carrying the notice, the channel and the outcome. On by default when a bus is enabled, and it is how an application keeps the delivery ledger it wants: this module records nothing, because a ledger belongs to whoever answers "why did they never receive it".

    attempts?: number

    How many times a queued delivery is retried. Defaults to what the queue does.

    channels?: ChannelConfig[]

    The channels this application configures.

    dedupe?: { store?: string; ttl?: number }

    How a repeated occurrence is recognised.

    Keys are held in @stone-js/cache, so the store is the one the application already chose, and this module stores nothing of its own. Without the cache module, deduplication does not happen and says so once: silently sending twice is the failure it exists to prevent.

    Type Declaration

    • Optionalstore?: string

      Which cache store holds them. Defaults to the application's default store.

    • Optionalttl?: number

      How long a key is remembered, in seconds. Defaults to a day.

    default?: string[]

    The channels a notification uses when it names none.

    Defaults to ['log'], which delivers nothing and says so on first use. That is deliberate: a default that quietly sent real mail would send it from the first test run.

    dispatch?: "inline" | "queue"

    Whether delivery is handed to a queue or performed in the request.

    Defaults to queue when @stone-js/queue is enabled, and to inline otherwise, saying so once. Queueing is what this module is shaped around: deciding and recording is fast, reaching a mail provider is not, and a request that waits for one is a request that times out on a function-as-a-service platform.

    notices?: NoticeDeclaration[]

    The notices this application declares, when it declares them in configuration rather than with @Notice. Both are read, and both say the same thing.

    queue?: string

    The queue to dispatch on. Defaults to the application's default queue.

    recipients?: (id: string) => Promiseable<Recipient>

    How to turn an id into a person.

    The one thing this module cannot ship. Point it at whatever already knows, and the address is read at send time rather than copied into a message.

    recipients: async (id) => await accounts.contactFor(id)
    
    templates?: Record<string, TemplateInput>

    Templates, for an application that does not carry a translation catalogue.

    When @stone-js/i18n is enabled, keys are looked up there instead, in the recipient's locale. These are the fallback, and the override: a key found here is used as it stands.