Configuration Inclusion

If you have multiple configurations using the same or similar kind of logic, it is possible to extract the common code into a separate configuration and by so reuse it across several use-cases.

There are two alternatives how to modularize your code, both explained below.

The reason why there are two different alternatives available is historical. In the first versions of TIF Cloud, there were no support for using the JavaScript module keywords import/export, thus the static code inclusion were added as a feature.

Later on, the Javascript import / export keywords were added.

Using JavaScript import / export

From one configuration you can export constants, functions etc and then import these from another.

Example:

sap/library.js

const myFunc = (name) => `Hello ${name} !`;

export { myFunc as hello };

sap/use-case.js

import { hello } from 'sap/library';

console.log(hello('TIF'));

You can use named exports or default exports.

When importing, the name of the configuration you import something from may omit the .js extension. You can include the extension if you want, but if the configuration uses the .js extension in the name, you are not required to do so.

Static Inclusion / Pre-processing Directive

To include the content of another configuration, one will use a special syntax like shown below:

//@include:NAME_OF_OTHER_CONFIG_TO_BE_INCLUDED

The include statements should for convenience be declared at the top of a configuration.

The //@include: directive is evaluated before any executions occur, it works like a pre-processor directive.

You can have nested include directives, but if there are any circular dependency - an error will be thrown.

Moreover, if the same configuration is included from more than one place, only the first inclusion is included, the others are omitted.

This allows declaring common code in one place only and reuse across multiple use cases.