Foblex Flow
Introduction
Introducing Foblex Flow
Installation and Rendering
Angular Compatibility
Changelog
Roadmap
Errors and Warnings
AI Agents
Styling
Styling Overview
Mixins and Scoping
Tokens and Overrides
Styling Recipes
Concepts
Event System
Selection System
Managed Flow State
New
Large-Flow Performance
Containers
Flow
Canvas
Nodes
Node
Drag Handle
Group
Resize Handle
Rotate Handle
Connectors
Connector
New
Output
Deprecated
Input
Deprecated
Outlet
Deprecated
Connection Rules
Migrate to Unified Connectors
Connections
Connection
Create Connection
Connection Marker
Snap Connection
Connection Waypoints
Interaction
Drag and Drop
Auto Pan
External Item
Zoom
Selection Area
Control Scheme
Accessibility
Integration
Shadow DOM and Angular Elements
New
Helpers
Background
Magnetic Lines
Magnetic Rects
Line Alignment (Legacy)
Minimap
Use Cases
Angular Node-Based UI Library
Angular Node Editor Library
Angular Workflow Builder
Angular Diagram Library
Angular AI Agent Builder
Angular Flowchart Library
React Flow Alternative
ngx-graph Alternative
React Flow vs Foblex Flow
Foblex Flow

Managed Flow State

Foblex Flow supports two explicit state models. The default remains event-driven: the application renders its own records, handles final interaction events, and writes the result to its own store. The opt-in withFlowState() feature manages graph record bookkeeping, supported gesture writeback, snapshots, selection, viewport state, and undo/redo.

In both modes, your application still owns domain meaning, validation, permissions, backend integration, and the decision about when and where to persist.

Choose the mode deliberately

Choose When it fits
Classic event-driven mode You already have an NgRx, signal, service, collaborative, or backend-synchronized graph store and want Foblex Flow to remain the rendering and interaction layer.
Managed Flow State You want typed graph records and editor history without wiring every supported gesture to application mutations yourself.

Managed state is never installed implicitly. Enable it for one flow through the component provider:

Render those records with normal Angular templates and the current unified connector API:

What the plugin writes automatically

Supported completed gestures update the managed records and normally become one history item:

  • connection creation and endpoint reassignment;
  • node and group movement, including a multi-selection drag;
  • deletion requested by the interaction or accessibility layer;
  • external palette item creation;
  • optional drop-to-group reparenting;
  • selection;
  • canvas pan and zoom.

Node and group geometry emitted through fNodeSizeChange / fGroupSizeChange, including user resize and auto-expand or auto-fit updates, is synchronized into the current records without creating a separate history item. Arbitrary content measurement that does not emit one of those outputs is not written to the store.

Programmatic mutations use the same history:

Use batch() for synchronous work. Use the paired beginBatch() and endBatch() APIs when one user action crosses an asynchronous render or ResizeObserver turn.

Persistence

snapshot() returns plain arrays plus the current selection and canvas transform. load() restores those slices and resets the history:

Treat persistence as application work: choose the storage format, schema version, migrations, authorization, and backend synchronization outside the canvas library.

Configuration

  • historyLimit defaults to 50.
  • selectionInHistory controls whether undo/redo walks selection changes. Selection is still included in snapshots.
  • canvasTransformInHistory controls whether pan and zoom enter undo/redo. The transform is still tracked for persistence.
  • canvasTransformDebounce defaults to 350ms so a wheel or pinch sequence becomes one settled history item.
  • connectionFactory and nodeFactory can shape or reject records created by gestures.
  • stateClass installs an FFlowState subclass when application-specific mutation behavior is required.

Current v1 boundaries

Managed state v1 does not automatically capture rotation or connection waypoint editing. Handle their existing final outputs and update the relevant record yourself. Node and group resize is synchronized automatically, but it amends the current state rather than creating a standalone undo step.

Connections reference connector ids rather than owner node ids. Before connectors render, including immediate mutations after load() or during SSR, the live connector ownership registry is unavailable. If you remove a node in that phase, calculate and remove its attached connection ids inside the same batch.

Continue

Edit this page on GitHub
In this article