repository·main·Indexed 13 days ago
https://github.com/FlowiseAI/FlowiseA low-code visual tool for building AI agents and workflows, allowing users to orchestrate LLMs, tools, and memory components. Version 3.1.4 includes support for horizontal scaling via a worker-based queue mode using Redis and a dedicated @flowiseai/agentflow React component for embedding the flow editor.
@flowiseai/agentflow is an embeddable React-based flow editor designed for building and visualizing AI agent workflows. It is built on top of ReactFlow and provides a visual canvas to connect LLMs, agents, tools, and logic nodes. It is currently in Dev status (version 0.0.0-dev.13), meaning the public API may change.To maintain modularity, dependencies in @flowiseai/agentflow must only flow downwards. Following these rules prevents circular dependencies and ensures that low-level layers remain decoupled from high-level features.
features/: Can import from atoms/, infrastructure/, and core/.infrastructure/: Can import from core/.atoms/: Can only import from core/types, core/theme, and core/primitives.core/: Is a leaf node and cannot import from any other layer.atoms/ must never import from features/ or infrastructure/.features/ must never import from other features/ directly. If logic is shared between features, it must be moved to core/.To maintain consistency within the @flowiseai/agentflow codebase, adhere to these architectural patterns:
Every directory must have an index.ts file. You should always import from the directory alias or the barrel file, never deep-link into specific files.
import { Button } from '@atoms'import { Button } from '@atoms/Button/Button'| Type | Convention | Example |
|---|---|---|
| Component | PascalCase.tsx | AgentFlowNode.tsx |
| Hook | camelCase.ts (with use prefix) | useFlowHandlers.ts |
| Logic/Types | camelCase.ts | flowValidation.ts |
| Styles | kebab-case (co-located) | canvas.css |
The core/ directory contains two types of utility folders with different import permissions. When adding a new utility, determine its dependency on domain concepts to choose the correct location:
core/primitives/: Contains domain-free, general-purpose functions (e.g., pure data transformations like getDefaultValueForType). These have no knowledge of nodes or flows and are safe to import from atoms/.core/utils/: Contains domain-aware utilities that understand node structures, flow data, or validation logic (e.g., initNode, getUniqueNodeId). These are only importable by features/ and infrastructure/.Flowise supports horizontal scaling through a worker-based queue mode. This allows you to handle increased workloads by adding more worker instances.
The workflow is as follows:
Tests are categorized into three tiers based on their impact and risk. When modifying code, you should add or update tests in the same Pull Request.
Must test. Includes pure business logic in infrastructure/ and critical hooks. Bugs here affect all SDK consumers.
useExecutionTree).Test when changing. Includes hooks that orchestrate polling and UI state.
useExecutionPoll, pagination, or filter hooks.Test if logic exists. Presentational components that are mostly JSX do not require tests. Only add tests if the component contains meaningful business logic (e.g., branching logic, filter predicates, or debounced handlers).
To maintain visual consistency and modularity, follow these interaction rules:
executions) should own its specific components (e.g., ExecutionsViewer.tsx) and hooks (e.g., useExecutionPoll.ts).core/.Each module (especially within features/) should use an index.ts file as a "Gatekeeper" to define its public API. This pattern enables encapsulation and improves tree-shaking by only exposing necessary symbols and keeping internal sub-components private.
Example features/canvas/index.ts implementation:
// ✅ Public API
export const nodeTypes = { ... }
export const edgeTypes = { ... }
export { ConnectionLine, AgentflowHeader, createHeaderProps }
export { useFlowNodes, useFlowHandlers, useDragAndDrop }
// Container components are re-exported for advanced usage
export { AgentFlowNode, AgentFlowEdge, StickyNote, IterationNode }
// ❌ Internal sub-components stay private within containers/components// features/canvas/index.ts
// ✅ Public API
export const nodeTypes = { ... }
export const edgeTypes = { ... }
export { ConnectionLine, AgentflowHeader, createHeaderProps }
export { useFlowNodes, useFlowHandlers, useDragAndDrop }
// Container components are re-exported for advanced usage
export { AgentFlowNode, AgentFlowEdge, StickyNote, IterationNode }
// ❌ Internal sub-components stay private within containers/componentsThe @flowiseai/agentflow examples provide two primary modes of operation:
BasicExample.tsx)Designed for minimal canvas integration without a database connection.
initialFlow.onFlowChange.onSave.fitView and clear refs.E2eExample.tsx)Designed for full integration with a running Flowise instance. Requires VITE_FLOW_ID for optimal behavior.
POST /api/v1/internal-prediction (with markdown rendering) and a Run Status panel for per-node execution results.VITE_API_TOKEN must have Create, Update, and Delete permissions for Agentflows.The useExecutionPoll hook manages automatic polling of execution states using setInterval.
Polling Logic:
execution.state === 'INPROGRESS': Polls every pollInterval ms.FINISHED, ERROR, TERMINATED, TIMEOUT, or STOPPED: The interval is cleared immediately.Options:
pollInterval={0}: Disables auto-poll entirely.refresh(): The hook returns a refresh function for manual trigger (e.g., for a refresh button).Tests are prioritized into three tiers based on risk and impact. When modifying a file, you should add or update tests in the same Pull Request.
High-risk business logic located in core/, infrastructure/, and critical hooks. A bug here affects all users.
useFlowHandlers.Orchestration logic for UI behavior.
Presentational components. Only test if they contain meaningful business logic or exported helper functions. Pure styling components (e.g., styled.ts, MainCard.tsx) do not require tests.
The useExecutionTree hook transforms a flat array of NodeExecutionData[] (from execution.executionData) into a hierarchical ExecutionTreeNode[]. It uses two sequential mechanisms:
previousNodeIds parent→child: Each non-iteration node attaches to the most recent instance of any node listed in its previousNodeIds. Nodes with empty or unmatched IDs become roots.parentNodeId and iterationIndex are grouped into virtual container nodes (isVirtualNode: true) under the iteration agent's most recent instance.Tree-node IDs are formatted as ${nodeId}_${arrayIndex} to ensure uniqueness when the same node runs multiple times (e.g., in a loop).