FluxFlow.Components.Control
3.0.2
dotnet add package FluxFlow.Components.Control --version 3.0.2
NuGet\Install-Package FluxFlow.Components.Control -Version 3.0.2
<PackageReference Include="FluxFlow.Components.Control" Version="3.0.2" />
<PackageVersion Include="FluxFlow.Components.Control" Version="3.0.2" />
<PackageReference Include="FluxFlow.Components.Control" />
paket add FluxFlow.Components.Control --version 3.0.2
#r "nuget: FluxFlow.Components.Control, 3.0.2"
#:package FluxFlow.Components.Control@3.0.2
#addin nuget:?package=FluxFlow.Components.Control&version=3.0.2
#tool nuget:?package=FluxFlow.Components.Control&version=3.0.2
FluxFlow.Components.Control
Standalone expression-driven control nodes for FluxFlow. They depend only on
FluxFlow.Nodes and FluxFlow.Mapping — no engine, registry, or runtime. You
new a node and LinkTo the next one.
Nodes
| Node | Shape | Purpose |
|---|---|---|
FilterNode<TInput> |
Input → Output |
Re-broadcasts messages whose payload matches an expression; drops the rest. |
WhenNode<TInput> |
Input → WhenTrue / WhenFalse |
Routes each message by expression result. |
Every message travels as a FlowMessage<T> envelope. FilterNode re-broadcasts
the surviving FlowMessage<TInput> on Output; WhenNode fans the original
message to WhenTrue (its primary Output) or WhenFalse. The routed message
carries the same correlation id as the input.
The package does not choose an expression language: each node takes an
IFlowExpressionEngine directly and compiles its predicate once at
construction, evaluating only the compiled form per message.
var options = new ControlExpressionOptions
{
Expression = "value > 10",
ExpressionId = "route-v1",
ExpressionName = "route-important",
InputType = "int"
};
await using var when = new WhenNode<int>(options, appExpressionEngine);
when.WhenTrue.LinkTo(highSink, new DataflowLinkOptions { PropagateCompletion = false });
when.WhenFalse.LinkTo(lowSink, new DataflowLinkOptions { PropagateCompletion = false });
await when.Input.SendAsync(FlowMessage.Create(42));
FilterNode works the same way:
await using var filter = new FilterNode<int>(
new ControlExpressionOptions { Expression = "value % 2 == 0", InputType = "int" },
appExpressionEngine);
filter.Output.LinkTo(evenSink, new DataflowLinkOptions { PropagateCompletion = false });
await filter.Input.SendAsync(FlowMessage.Create(2));
Expression-backed constructors require a non-empty Expression, non-empty
InputType, and BoundedCapacity greater than zero. Invalid options fail fast
during node construction before the input pipeline is created.
Custom mapping context
By default the predicate sees the payload as the input and value variables.
Pass an IFlowMapContextFactory<TInput> to shape the variables an expression
engine evaluates against:
var node = new FilterNode<AppMessage>(options, appExpressionEngine, new AppMessageContextFactory());
You can also supply an already-compiled IFlowPredicate<TInput> directly when
you do not want the node to own compilation:
var node = new WhenNode<int>(options, myPredicate, engineName: "my-engine");
The compiled-predicate constructors do not require Expression, but they still
validate InputType and BoundedCapacity because those values drive
diagnostics and queue sizing.
Behavior
Expression-evaluation failures emit a FlowError on Errors (carrying the
input's correlation id and a Code from ControlErrorCodes) and the node keeps
processing later messages. Per-message diagnostics — flow.filter.passed /
flow.filter.rejected / flow.filter.failed and flow.when.routed /
flow.when.failed (see ControlDiagnosticNames) — flow on the Events port
with input type, engine, expression id, expression name, route, and pass/fail
metadata where available.
Runtime timing
Error and event timestamps use the node's clock (default TimeProvider.System).
Provide a deterministic clock for tests:
new FilterNode<int>(options, engine, clock: new FakeTimeProvider(timestamp));
Composition
Add FluxFlow.Components.Control.Composition when a host wants to instantiate
control nodes from FluxFlow.Composition fluent/config definitions. That
optional package registers closed generic FilterNode<TInput> and
WhenNode<TInput> factories.
services.AddKeyedSingleton<IFlowExpressionEngine>("default", expressionEngine);
services
.AddFluxFlowComposition(configuration)
.RegisterNodes(registry => registry
.RegisterFilter<AppMessage>()
.RegisterWhen<AppMessage>());
Use custom node type names when one host needs several input shapes:
registry
.RegisterFilter<OrderMessage>("flow.filter.order")
.RegisterWhen<HttpResponseOutput>("flow.when.http-response");
Composition resolves the expression engine from the host-owned keyed engine
resource. Optional host-owned keyed contextFactory and clock resources can
provide custom expression variables and deterministic diagnostics. The
configured InputType remains diagnostic metadata; CLR port types come from
the closed generic registration. Invalid ControlExpressionOptions, such as a
missing expression, blank inputType, or non-positive boundedCapacity, fail
during composition build and surface as factory diagnostics when build failures
are configured as diagnostics.
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net8.0 is compatible. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. net9.0 was computed. net9.0-android was computed. net9.0-browser was computed. net9.0-ios was computed. net9.0-maccatalyst was computed. net9.0-macos was computed. net9.0-tvos was computed. net9.0-windows was computed. net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- FluxFlow.Mapping (>= 1.0.3)
- FluxFlow.Nodes (>= 1.2.0)
-
net8.0
- FluxFlow.Mapping (>= 1.0.3)
- FluxFlow.Nodes (>= 1.2.0)
- System.Threading.Tasks.Dataflow (>= 9.0.4)
NuGet packages (1)
Showing the top 1 NuGet packages that depend on FluxFlow.Components.Control:
| Package | Downloads |
|---|---|
|
FluxFlow.Components.Control.Composition
Optional FluxFlow.Composition registration helpers for standalone control nodes over host-owned keyed expression resources. |
GitHub repositories
This package is not used by any popular GitHub repositories.
| Version | Downloads | Last Updated |
|---|---|---|
| 3.0.2 | 142 | 7/3/2026 |
| 3.0.1 | 166 | 7/2/2026 |
| 3.0.0 | 117 | 6/19/2026 |
| 2.0.0 | 139 | 6/18/2026 |
| 1.2.1 | 120 | 6/15/2026 |
| 1.2.0 | 417 | 6/12/2026 |
| 1.1.0 | 115 | 6/5/2026 |
| 1.0.0 | 123 | 6/4/2026 |
| 0.3.0-alpha.1 | 248 | 6/2/2026 |
| 0.2.1-alpha.1 | 74 | 6/2/2026 |
| 0.2.0-alpha.1 | 94 | 6/1/2026 |
| 0.1.0-alpha.1 | 108 | 6/1/2026 |
Adds the shared FluxFlow package icon. No source, API, or dependency changes.