Principle:FlowiseAI Flowise Node Parameter Configuration
| Attribute | Value |
|---|---|
| Source Repository | FlowiseAI/Flowise |
| Domain | Chatflow_Creation |
| Workflow | Chatflow_Creation |
| Last Updated | 2026-02-12 |
Overview
Technique for dynamically updating node configuration parameters within a reactive canvas state, with conditional visibility of dependent fields. In a visual flow editor, nodes expose configurable parameters. When a user changes a parameter value, the system must update the node's input state, recalculate which parameters are visible (some depend on other parameter values), and trigger a re-render.
Motivation
Node configuration in a visual AI builder is inherently dynamic. A node's available parameters often depend on other parameter values:
- An LLM node might show different options depending on which model provider is selected.
- A retrieval node might hide vector store connection fields when a direct document input mode is chosen.
- An agent node might show or hide tool configuration based on whether tool usage is enabled.
Without conditional visibility, users would see all possible parameters simultaneously, leading to cluttered and confusing configuration panels. Dynamic parameter visibility ensures that only relevant fields are displayed at any given time.
Description
The Node Parameter Configuration principle implements a reactive state management pattern where parameter changes trigger a visibility recalculation pass. The process follows an immutable update pattern (clone, modify, set) with change detection to avoid unnecessary re-renders.
Update Flow
- User interaction -- The user changes a parameter value in the node's settings panel (e.g., selects a different model, toggles a boolean, enters text).
- Event dispatch -- The input component calls
onNodeDataChange({ nodeId, inputParam, newValue })with the target node ID, the parameter definition, and the new value. - State update -- The handler clones the node's current inputs, applies the new value, and creates an updated inputs object.
- Visibility recalculation --
showHideInputParams()is called with the updated inputs to determine which parameters should be visible. Each parameter'sdisplayflag is set totrueorfalse. - Hidden field cleanup -- Any input keys whose corresponding parameter has
display === falseare removed from the inputs object, ensuring hidden parameters do not carry stale values. - Change detection -- The updated parameter list is compared with the current one using deep equality (
isEqualfrom lodash). Only if there are actual changes does the system callsetNodes()to trigger a React re-render.
Conditional Visibility Rules
Parameters can declare show and hide conditions in their definitions:
{
name: 'maxTokens',
type: 'number',
label: 'Max Tokens',
show: {
model: ['gpt-4', 'gpt-3.5-turbo'] // Only visible when model is one of these
}
}
The visibility engine supports multiple comparison modes:
- Exact match -- Compare a single value against a single value.
- Array inclusion -- Check if the current value is in an array of allowed values.
- Regex matching -- Match the current value against a regex pattern.
- Boolean comparison -- Direct boolean equality.
- Object deep equality -- Deep comparison using lodash
isEqual.
Theoretical Basis
This principle is grounded in reactive state management with immutable update semantics:
- Immutable update pattern -- The node's inputs are never mutated in place. Instead, a new inputs object is created with the updated value, preserving React's ability to detect changes via reference comparison.
- Derived state computation -- Parameter visibility is a derived state computed from the current inputs. Rather than storing visibility separately and keeping it in sync, it is recomputed on every change, following the principle of a single source of truth.
- Change detection guard -- Deep equality comparison (
isEqual) before callingsetNodes()prevents unnecessary re-renders when a change to one node's parameters does not actually affect the parameter list. This is a performance optimization for large graphs. - Declarative visibility rules -- The
show/hideconditions on parameter definitions are declarative specifications that the visibility engine interprets. This separates the "what" (which conditions control visibility) from the "how" (the evaluation logic).
Usage
Use this principle when implementing interactive node configuration panels in a visual flow editor with conditional field visibility. It applies to:
- Any scenario where changing one parameter should show or hide other parameters.
- Node configuration forms that need reactive updates without full page refreshes.
- Systems where parameter visibility rules are defined declaratively in the node schema.