Workbench
NOOP Steps
NOOP (No Operation) steps are a powerful feature in Motia that serve multiple purposes:
- Modeling external processes, webhooks and integrations
- Representing human-in-the-loop activities
- Creating custom visualizations in the workbench
- Testing flows during development
Currently, NOOP steps are only supported in TS or JS
File Structure
NOOP steps require two files with the same base name:
stepName.step.ts
- Contains the step configurationstepName.step.tsx
- Contains the UI component (optional)
Step Configuration File (.ts)
UI Component File (.tsx)
Example: Webhook Testing
Here's a complete example of a NOOP step that simulates webhook events:
Representing External Processes
NOOP steps represent parts of your workflow that happen outside your system. Common examples include:
Webhook Callbacks
Human Approvals
External System Integration
Physical Processes
Visualization in Workbench
NOOP steps are visually represented in the Motia Workbench with the following characteristics:
- Distinct node representation with clear input/output handles
- Visual indicators for virtual event connections
- Status indicators for waiting states
- Clear visualization of external system dependencies
Custom UI
You can enhance your NOOP steps with custom React components for better visualization:
Best Practices
Category | Guidelines |
---|---|
File Organization | • Keep configuration and UI code in separate files • Use .step.ts for configuration• Use .step.tsx for UI components |
UI Components | • Use functional React components • Include proper TypeScript types • Follow Tailwind's utility classes • Keep components minimal and focused • Design clear visual connection points • Always include BaseHandle components for flow connections |
Configuration | • Always include virtualSubscribes (even if empty)• Use descriptive names for virtual events • Include clear descriptions • Use descriptive, action-oriented names |
External Process Modeling | • Document expected timeframes and SLAs • Define all possible outcomes and edge cases • Use exact API route matching |
Testing | • Create isolated test flows • Use realistic test data • Handle errors gracefully • Implement clear status indicators • Label test steps explicitly • Provide visual feedback for actions |
Component Reference
Core Imports
Import | Purpose |
---|---|
BaseHandle | A React component that renders connection points for nodes in the workflow. Used to define where edges (connections) can start or end on a node. |
EventNodeProps | (TypeScript only) Interface defining the properties passed to node components, including node data, selected state, and connection information. |
Position | (TypeScript only) Enum that specifies the possible positions for handles on a node (Top, Right, Bottom, Left). Used to control where connection points appear. |
Handle Placement
Handle Type | Position |
---|---|
Input Handles | Position.Top |
Output Handles | Position.Bottom |
Flow Direction | Top to bottom |
Styling Guidelines
Category | Guidelines |
---|---|
Colors | Use semantic colors to indicate state (success, error, pending) |
States | • Implement clear visual indicators for active/inactive states • Use subtle animations for state transitions |
Design System | • Follow your project's design tokens • Maintain consistent spacing and padding • Use standard border radiuses • Ensure high contrast for readability • Use consistent font sizes (14px-16px) |
Need help? See our Community Resources for questions, examples, and discussions.