ConfigurableOperationDef

Any class which extends ConfigurableOperationDef works in the same way: it takes a config object as the constructor argument. That config object extends the ConfigurableOperationDefOptions interface and typically adds some kind of business logic function to it.

For example, in the case of ShippingEligibilityChecker, it adds the check() function to the config object which defines the logic for checking whether an Order is eligible for a particular ShippingMethod.

The args property

The key feature of the ConfigurableOperationDef is the args property. This is where we define those arguments that are exposed via the Admin UI as data input components. This allows their values to be set at run-time by the Administrator. Those values can then be accessed in the business logic of the operation.

The data type of the args can be one of ConfigArgType, and the configuration is further explained in the docs of ConfigArgs.

Dependency Injection

If your business logic relies on injectable providers, such as the TransactionalConnection object, or any of the internal Vendure services or those defined in a plugin, you can inject them by using the config object's init() method, which exposes the Injector.

Here's an example of a ShippingCalculator that injects a service which has been defined in a plugin:

Example

Translations

The description of the operation, plus the label and description of each arg, may be defined inline as a LocalizedStringArray. They may also be supplied from the server-side message catalogs, under the configurableOperation namespace, using keys of the form:

where <type> is one of ConfigurableOperationDefType. Call ConfigurableOperationDef.getTranslationKeys to see the exact keys for a given operation. Catalog entries take precedence over the inline arrays for the same language, which means the strings of a third-party operation can be overridden by registering translations for its keys via I18nService.addTranslation(). A key which does not match any operation is simply never read, so a typo produces no error — the inline string is used instead.

The description and the arg labels are resolved to a single string before being sent, in the language requested by the client. Select option labels are the exception: they are sent as a full LocalizedStringArray with the catalog translation merged in, because the Admin UI resolves them against the administrator's display language, which is a separate setting from the content language sent with the request.