Sharing Code

Create Javascript functions and constants that can be shared across your logic rules.

To keep your code clean, you can add small, testable JavaScript modules containing functions and constants that can be accessed from multiple Logic Rules. A Shared Code module exports named constants and functions. Logic Rules import those exports and use them to drive form interactions.

Why use shared code

• Share common helpers across many forms and rules.

• Keep Logic Rules lean and focused on orchestration.

• Improve testability and readability.

How it works

• You author a Shared Code module in its own code editor.

• You export named constants and functions from that file.

• In a Logic Rule, you import the names you need from the Shared Code by its key.

• You call the imported functions or read the constants, then set field values as usual.

Authoring rules and constraints

Use only named exports. The editor validates your code and blocks unsupported syntax.

Allowed

• export const NAME = ...

• export const fn = (...args) => { ... }

• export function NAME(...args) { ... }

Disallowed

• Default exports, for example export default ...

• Aggregate or aliased exports, for example export { a, b as c } [from '...'], export * from '...'

• Variable exports with let or var, for example export let x = ..., export var x = ...

• Destructured constant exports, for example export const { a } = ..., export const [a] = ...

• Type level exports, for example export class, export enum, export interface, export type

Notes

• Every export const must have an initializer.

• Prefer pure functions. Avoid relying on ambient globals or browser state.

• Keep exports small and single purpose.

Creating Shared Code

1. Create a new Shared Code module and give it a clear key, for example Logic-1.

2. Add your exports in the editor.

3. Save. The validator will flag unsupported patterns before save.

Video walkthrough contents

The accompanying video demonstrates the full workflow end to end.

• Create a Shared Code module with named exports.

• Save and confirm validation passes.

• Open a form’s Logic Rules and import from the Shared Code module name.

• Wire Rule 1 to a button to randomize two TextFields.

• Wire Rule 2 to a button that reads an index from a TextField and writes the selected color to a Hidden field.

• Run both interactions to verify values update as expected.

Example Shared Code module

// Exports a few helpers for colors and fruits.

const favoriteColors = ['red', 'orange', 'green', 'blue'];
const fruit = ['apple', 'blueberry', 'cherry', 'strawberry'];

export function randomColor() {
  const index = Math.floor(Math.random() * favoriteColors.length);
  return favoriteColors[index];
}

export const randomFruit = () => {
  const index = Math.floor(Math.random() * fruit.length);
  return fruit[index];
};

export function chooseColor(value) {
  const colorIndex = Number(value);

  if (!value || colorIndex < 0 || colorIndex > favoriteColors.length - 1) {
    return '?';
  }

  return favoriteColors[colorIndex];
}

Importing into a Logic Rule

Use the Shared Code Module name as the source. Import only the names you need.

Example 1: Randomize two TextFields on button click

Rule code

import { randomColor, randomFruit } from 'Logic-1';

Value_Color.value = randomColor();
Value_Fruit.value = randomFruit();

What it does

• Each click of the “Random Color and Fruit” button runs the rule.

• Value_Color and Value_Fruit TextFields update with new random values.

Example 2: Map a user input index to a color

Rule code

import { chooseColor } from 'Logic-1';

selected_color.value = chooseColor(Value_Color_Index.value);

What it does

• Each click of the “Choose Color” button runs the rule.

• The rule reads the Value_Color_Index TextField, converts it to a number, then calls chooseColor.

• The result is assigned to a Hidden field named selected_color.

Import source and naming

• Use the Shared Code name as the import source string, for example 'Logic-1'.

• If the key changes, update imports in any Logic Rules that reference it.

Validation behavior and common errors

• Default export used Replace with a named export. Example: export function helper() {}.

• Export without initializer Every export const must be initialized. Example: export const X = 1.

• Unsupported export forms Remove export *, export { a as b }, or destructured exports.

• Variable exports with let or var Use const or function for exports.

• Type level exports Keep the file runtime only. Remove class, enum, interface, and type exports.

Best practices

• Keep modules small. Each Shared Code module should serve a single purpose.

• Validate inputs inside exported functions. Return safe defaults rather than throwing where possible.

• Avoid non-determinism unless you need it. For randomness, consider seeding or documenting expected behavior.

• Document each export at the top of the file with a brief comment.

Troubleshooting

• Import not found Verify the Shared Code module name matches the string in your import statement. Save your shared code after edits.

• Validation error on save Compare your code against the Allowed and Disallowed lists above, then adjust.