Export and import

In Cube, your data model is code, and code is much easier to manage when it is in small, digestible chunks. It is best practice to keep files small and containing only relevant and non-duplicated code. As your data model grows, maintaining and debugging is much easier with a well-organized codebase.

Cube data models in JavaScript supports ES6-style export (opens in a new tab) and import (opens in a new tab) statements, which allow writing code in one file and sharing it, so it can be used by another file or files.

There are several typical use cases in Cube where it is considered best practice to extract some variables or functions and then import it when needed.

Managing constants

Quite often, you may want to have an array of test user IDs to exclude from your analysis. You can define it once and export it like this:

// in constants.js
export const TEST_USER_IDS = [1, 2, 3, 4, 5];

Later, you can import into the cube whenever needed:

// in Users.js
import { TEST_USER_IDS } from "./constants";
 
cube(`users`, {
  // ...
 
  measures: {
    // ...
  },
 
  dimensions: {
    // ...
  },
 
  segments: {
    exclude_test_users: {
      sql: `${CUBE}.id NOT IN (${TEST_USER_IDS.join(", ")})`,
    },
  },
});

Helper functions

You can assign some commonly used SQL snippets to JavaScript functions. The example below shows a parsing helper function, which can be used across any number of cubes to correctly parse a date if it was stored as a string.

You can read more about working with string time dimensions here.

// in helpers.js
export const parseDateWithTimeZone = (column) =>
  `PARSE_TIMESTAMP('%F %T %Ez', ${column})`;

// in events.js
import { parseDateWithTimeZone } from "./helpers";
 
cube(`events`, {
  sql_table: `events`,
  // ...
 
  dimensions: {
    date: {
      sql: `${parseDateWithTimeZone("date")}`,
      type: `time`,
    },
  },
});

Import from parent directories

You may need to import from parent directories as Cube flattens nested directories. The example below shows a correct way to import a helper function, which is located in a parent directory.

.
├── README.md
├── cube.js
├── package.json
└── model
    ├── utils.js
    └── sales
        └── orders.js

// in model/sales/orders.js
import { capitalize } from "./schema_utils";

// in model/utils.js
export const capitalize = (s) => s.charAt(0).toUpperCase() + s.slice(1);

Expose environment variables to data model files

A common use-case is to disable pre-aggregations unless running in "production" or "staging" environments. The best approach is to add an environment variable and make it available in data model files.

In the example below we have the following file structure:

.
├── README.md
├── cube.js
├── package.json
├── utils.js
└── model
    └── sales
        └── orders.js

In the utils.js file we read the environment variable and expose it. We will default the environment variable to the value dev.

// in utils.js
const environment =
  typeof process.env.ENVIRONMENT === "undefined"
    ? "dev"
    : process.env.ENVIRONMENT.toLowerCase();
exports.environment = () => environment;

In the data model file, the definition will change depending on the value of the environment value.

// in model/sales/orders.js
import { environment } from "../utils";
const isProdOrStaging = ["prod", "staging"].includes(environment());
 
cube(`orders`, {
  // ...
 
  pre_aggregations: isProdOrStaging
    ? {
        main: {
          // ...
        },
      }
    : {}, // No pre-aggregations unless environment is prod or stagging
});