Principle:FlowiseAI Flowise Node Initialization
| Attribute | Value |
|---|---|
| Source Repository | FlowiseAI/Flowise |
| Domain | Chatflow_Creation |
| Workflow | Chatflow_Creation |
| Last Updated | 2026-02-12 |
Overview
Technique for transforming a node component definition into a fully initialized, interactive canvas node with configured inputs, outputs, and anchors. When a user drops a node onto the canvas, the raw component definition must be transformed into a live node instance. This involves generating a unique node ID, categorizing inputs into parameter inputs (rendered as form fields) vs anchor inputs (rendered as connection handles), initializing output anchors, and setting default values.
Motivation
A node component definition from the server registry is a schema -- it describes what a node can do but is not yet a live, interactive instance. The initialization step bridges the gap between schema and instance by:
- Generating identity -- Each placed node needs a unique ID to be addressable within the graph.
- Classifying inputs -- Inputs must be split into form-configurable parameters (rendered in the node's settings panel) and connection anchors (rendered as draggable handles on the node's border).
- Setting defaults -- All configurable parameters need initial values so the node is usable immediately after placement.
- Creating output handles -- Output anchors must be generated with typed IDs that encode the node's base classes, enabling type-checked connections.
Description
The Node Initialization principle transforms a server-provided component definition into a fully interactive ReactFlow node instance. The core transformation follows an input classification algorithm that determines how each input is rendered.
Input Classification
The algorithm iterates over the node definition's inputs array and classifies each input based on its type field:
- Whitelist types become inputParams (rendered as form fields in the settings panel):
asyncOptions,asyncMultiOptions,options,multiOptionsarray,datagridstring,number,boolean,passwordjson,code,datefile,foldertabs,conditionFunction
- All other types become inputAnchors (rendered as connection handles that accept edges from other nodes).
This classification is deterministic and based solely on the type string, making it predictable and consistent across all node types.
Initialization Steps
- Generate unique ID -- Produce a unique node ID by combining the component name with an incrementing suffix (e.g.,
chatOpenAI_0,chatOpenAI_1). - Classify inputs -- Iterate over the definition's inputs array, splitting into
inputParamsandinputAnchorsbased on the whitelist. - Assign input IDs -- Each input gets an ID formatted as
{nodeId}-input-{inputName}-{inputType}. - Handle credentials -- If the definition includes a
credentialfield, it is prepended toinputParamsas a special credential selector. - Initialize output anchors -- Output anchors are created with IDs encoding the node's base classes (e.g.,
{nodeId}-output-{name}-{baseClasses.join('|')}). The format differs between standard chatflows and agentflows. - Set default values -- All input parameters are initialized to their
defaultvalue or empty string. - Apply visibility rules --
showHideInputParamsandshowHideInputAnchorsare called to determine initial visibility based on default values and conditional display rules.
Theoretical Basis
The transformation follows an input classification algorithm using a whitelist-based approach:
- Whitelist classification -- A predefined set of "primitive" input types identifies which inputs are form-configurable. Any type not in this whitelist is assumed to be a complex type that requires data from another node, and thus becomes a connection anchor. This is a closed-world assumption: known types are parameters, unknown types are anchors.
- ID encoding -- Node, input, and output IDs encode structural information (node ID, input name, type, base classes) using a dash-separated format. This allows the connection validator to extract type information from handle IDs without additional lookups.
- Schema-to-instance transformation -- The initialization converts a declarative schema (what the node can accept) into an imperative instance (what the node currently holds), with defaults and visibility state.
Usage
Use this principle when a user adds a new component to a visual flow canvas via drag-and-drop. It applies whenever:
- A raw node definition from the server registry needs to be instantiated on the canvas.
- Input types need to be classified as form fields vs. connection handles.
- Default values and visibility states need to be computed for a newly placed node.