Skip to content

Static vs Dynamic

In the last page you set TextProcessor's operation to capitalize in its configuration panel. To change it, you opened the editor, picked a different value, saved.

Configuration is a value you decide at design time. But TextProcessor also exposes operation as an input port — meaning another node can supply the value at run time. Same setting, two ways to source it.

This page shows the difference and why it matters.

What you will learn

  • How a single value can be sourced from configuration or a port
  • How a connected port overrides the configured default
  • When to lean on one vs. the other

The setup

You should still have:

ChatInput ──▶ TextProcessor ──▶ ChatOutput

with TextProcessor configured to capitalize.

Step 1: Add a TextInput node

  1. Click + and add a Text Input (under Text & Output).
  2. Click the new node and set its defaultValue to uppercase.

This node is small and dumb — it outputs whatever string you typed. We're going to use it as the "decision" about which operation TextProcessor should apply.

Step 2: Wire it into TextProcessor's operation port

Drag from TextInput's text output to TextProcessor's operation input port.

┌─────────────┐
│  TextInput  │
│ "uppercase" │
└──────┬──────┘
       │ text
       │
       │       operation
       ▼
┌─────────────┐         ┌────────────────┐         ┌──────────────┐
│  ChatInput  │ message │ TextProcessor  │  text   │  ChatOutput  │
│             ├────────▶│  capitalize    ├────────▶│              │
└─────────────┘         └────────────────┘         └──────────────┘

Save the workflow.

Step 3: Test

Open the Playground and type hello world.

You should get back HELLO WORLD — even though TextProcessor's configured operation is still capitalize.

The connected port wins. The configured value only kicks in when no edge supplies one.

Step 4: Change behavior without rewiring

Open TextInput in the editor. Change its defaultValue from uppercase to lowercase. Save.

Send Hello WORLD in the Playground. You get back hello world.

You changed the workflow's behavior without touching TextProcessor and without changing a single edge.

What this proves

The same logical setting — which operation should run — can live in two places:

  • As configuration (a static default on TextProcessor): set once when designing the workflow, identical on every run.
  • As a port (an input edge from another node): computed on every run, and free to vary based on whatever upstream logic you build.

This is the distinction Flow › Chapter 7 ended on. Now you've felt it: ports are dynamic, config is static, and the same value can be either depending on how you wire the workflow.

Which should you use?

Use config when Use a port when
The value is fixed for this workflow's purpose The value depends on the input or upstream logic
You want a simpler graph You want runtime flexibility
Different deployments don't need different values The same workflow needs to behave differently per run

A general rule: start with config. Promote a setting to a port the moment you find yourself wishing it could change per run.

Next

Re-building the Date Workflow → — same pattern, but with a real-world processor that needs both config and ports.