Modules Overview

Reuse ordinary code with local JavaScript or TypeScript modules. Reuse workflow-shaped behavior with a WOML definition.

Choose a module

Use a local module for calculations, parsing, API wrappers, and project utilities. Named exports appear under services.<moduleName> and can be called many times.

Choose a reusable definition

Use a reusable WOML step when the component needs props, durable execution, retries, managed effects, or lifecycle hooks. Reusable definitions are components, not independently running workflows.

Use Workflow Communication Overview when the other unit should own a separate run.

Start inline, extract when the idea becomes reusable

Keep logic in <script> while it is short and belongs to one workflow. Extract a local module when the same calculation, parser, template, or API wrapper is useful in several steps or deserves ordinary unit tests.

Create a reusable WOML step when the reused unit needs a durable step identity, props, retry attributes, terminal presentation, or reusable lifecycle behavior.

Keep a runnable workflow separate when it owns independent triggers, runtime policy, history, cancellation, or a business result. Runnable .woml files are never imported as hidden steps; use workflow communication instead.

Compare the three reuse levels

This distinction keeps reuse explicit without forcing users to understand internal execution categories. The author chooses by product meaning; WOML handles packaging and supervision behind the scenes.