Add output-based switch case condition builder #12

New issue

Closed

opened 2026-09-16 10:12:34 +02:00 by morten-olsen · 1 comment

morten-olsen commented

2026-09-16 10:12:34 +02:00

Owner

Context

Switch cases currently require users to author evaluation expressions by hand. This is powerful but makes ordinary branching harder to discover, validate, and compose. Most cases should be expressible as a typed comparison against an output produced earlier in the workflow, while advanced users must retain full expression support.

Scope

Add an output-based condition mode for each switch case alongside the existing expression mode.
In output-based mode, present a three-part condition builder:
1. a left operand output picker that offers values available at that point in the workflow;
2. an operator picker constrained by the selected output's declared type; and
3. a right-hand comparison-value editor only when the selected operator requires one.
Make the comparison-value editor type-aware. It must validate and serialize values according to the selected output type rather than treating every value as an untyped string.
Support the single-comparison operators already meaningful for each supported type. Examples include equality/inequality for compatible values, ordering for ordered values, and boolean/null checks without an irrelevant right-hand editor. Do not invent coercions between incompatible types.
Preserve the existing expression-based mode for arbitrary/advanced conditions. Existing saved switch expressions must continue to load and execute without migration loss.
Represent both modes through the existing switch/evaluation model and validation boundary so execution, dry-run/testing, persistence, and the future authoring tools have one canonical semantic contract.
Give validation errors in the builder for unavailable outputs, unsupported operators, malformed comparison values, and type mismatches before the user saves the workflow.

Non-goals

Do not remove, rewrite, or restrict hand-authored expression conditions.
Do not add compound conditions (and / or) in this issue; each output-based case contains one comparison.
Do not add implicit type coercion or node-specific comparison semantics.

Acceptance

A user can create a switch case by selecting an in-scope prior output, an operator permitted for its type, and an appropriately typed comparison value where required.
The right-hand editor is omitted for unary operators and rejects values incompatible with the selected output type.
The condition executes with the same result in the editor's test/dry-run path and the durable workflow engine.
Invalid output references, invalid operator/type combinations, and invalid right-hand values are blocked with actionable diagnostics and do not persist partial conditions.
Users can explicitly choose expression mode for a case and author an advanced expression; existing expression-based cases remain editable and execute unchanged.
Focused tests cover typed operator availability, comparison evaluation, unary conditions, invalid conditions, persistence round trips, and legacy expression-mode compatibility.

## Context Switch cases currently require users to author evaluation expressions by hand. This is powerful but makes ordinary branching harder to discover, validate, and compose. Most cases should be expressible as a typed comparison against an output produced earlier in the workflow, while advanced users must retain full expression support. ## Scope - Add an output-based condition mode for each switch case alongside the existing expression mode. - In output-based mode, present a three-part condition builder: 1. a left operand output picker that offers values available at that point in the workflow; 2. an operator picker constrained by the selected output's declared type; and 3. a right-hand comparison-value editor only when the selected operator requires one. - Make the comparison-value editor type-aware. It must validate and serialize values according to the selected output type rather than treating every value as an untyped string. - Support the single-comparison operators already meaningful for each supported type. Examples include equality/inequality for compatible values, ordering for ordered values, and boolean/null checks without an irrelevant right-hand editor. Do not invent coercions between incompatible types. - Preserve the existing expression-based mode for arbitrary/advanced conditions. Existing saved switch expressions must continue to load and execute without migration loss. - Represent both modes through the existing switch/evaluation model and validation boundary so execution, dry-run/testing, persistence, and the future authoring tools have one canonical semantic contract. - Give validation errors in the builder for unavailable outputs, unsupported operators, malformed comparison values, and type mismatches before the user saves the workflow. ## Non-goals - Do not remove, rewrite, or restrict hand-authored expression conditions. - Do not add compound conditions (`and` / `or`) in this issue; each output-based case contains one comparison. - Do not add implicit type coercion or node-specific comparison semantics. ## Acceptance - A user can create a switch case by selecting an in-scope prior output, an operator permitted for its type, and an appropriately typed comparison value where required. - The right-hand editor is omitted for unary operators and rejects values incompatible with the selected output type. - The condition executes with the same result in the editor's test/dry-run path and the durable workflow engine. - Invalid output references, invalid operator/type combinations, and invalid right-hand values are blocked with actionable diagnostics and do not persist partial conditions. - Users can explicitly choose expression mode for a case and author an advanced expression; existing expression-based cases remain editable and execute unchanged. - Focused tests cover typed operator availability, comparison evaluation, unary conditions, invalid conditions, persistence round trips, and legacy expression-mode compatibility.

morten-olsen commented

2026-09-16 10:12:38 +02:00

Author

Owner

Tracking decision: after this single-comparison output-condition builder lands, create a separate Forgejo ticket for compound switch-case conditions. That follow-up should let users join multiple typed comparisons with explicit and / or operators while preserving expression mode for cases that need arbitrary evaluation.

Tracking decision: after this single-comparison output-condition builder lands, create a separate Forgejo ticket for compound switch-case conditions. That follow-up should let users join multiple typed comparisons with explicit `and` / `or` operators while preserving expression mode for cases that need arbitrary evaluation.

morten-olsen referenced this issue

2026-09-17 07:48:44 +02:00

Add compound AND/OR switch conditions #24

morten-olsen closed this issue

2026-09-17 07:48:51 +02:00

morten-olsen referenced this issue from a commit

2026-09-17 10:10:31 +02:00

feat(switch): add compound AND/OR branch conditions

morten-olsen referenced this issue

2026-09-17 10:16:49 +02:00

Add compound AND/OR switch conditions #24

morten-olsen referenced this issue