I built a React circuit editor in a day with Workflow Builder

Kacper Cierzniewski — Mon, 01 Jun 2026 14:00:00 +0000

In short

Workflow Builder is generic enough to build non-workflow tools. In one day I built an interactive electrical-circuit editor with custom Battery, Switch, Lightbulb and Resistor nodes, a sub-200-line plugin that solves Ohm's law on every diagram change, and an LED-vs-incandescent cost comparison showing ~7× lower running cost for LEDs at the same brightness.

Background

As a frontend engineer at Synergy Codes I usually work on projects built from scratch. In my latest project we spent a lot of time building a custom diagram tool for electrical circuits, and I wanted to see how far I could get with Workflow Builder instead, in roughly one day of work.

The end result is a small interactive circuit editor with batteries, switches, resistors, lightbulbs, meters and an energy-cost calculator that compares LED and incandescent bulbs. This is the writeup of that day.

Reading the docs first

Before opening the editor I went through the documentation. Two things stood out.

First, there is a lot of it. Not only an API reference (which I would expect), but a proper introduction, an architecture overview, and a set of guides covering the things you actually need: custom nodes, plugins, persistence, JsonForms control. For a relatively young SDK that was a pleasant surprise.

Second, the docs are very explicit that Workflow Builder is the editor layer and execution is up to you. The framing matters, because it sets expectations: the SDK is going to give you the hooks rather than the answers.

Genericity is the keyword

The thing that makes Workflow Builder usable for something like a circuit editor is that almost nothing about it is workflow-specific.

Building custom nodes

Each node is described by a JSON Schema and a UI schema. There is a long list of building blocks already in the SDK (text inputs, labels, dropdowns, switches, accordions), and you arrange them in a vertical layout that drives the properties panel. The pattern is 4 small files per node, documented in Add a custom node. I will show what that looks like further down.

Embedding it as a React component

Workflow Builder ships as a React component on npm (@workflowbuilder/sdk), so dropping it into an existing app is a one-liner. You install the package, import WorkflowBuilder and its stylesheet, and mount <WorkflowBuilder.Root /> anywhere in your tree. All configuration – node types, plugins, persistence strategy, layout direction – is passed as props on that component, so the editor stays declarative and there is no separate factory or builder step to keep in sync.

import { WorkflowBuilder } from '@workflowbuilder/sdk';
import '@workflowbuilder/sdk/style.css';

import { demoPaletteItems } from './features/workflowbuilder/palette';
import { plugin as circuitSolverPlugin } from './features/workflowbuilder/plugins/circuit-solver/plugin-exports';
import { plugin as circuitReadoutsPlugin } from './features/workflowbuilder/plugins/circuit-readouts/plugin-exports';

function App() {
  return (
    <WorkflowBuilder.Root
      name="Bulb Comparison"
      layoutDirection="RIGHT"
      nodeTypes={demoPaletteItems}
      integration={{ strategy: 'localStorage' }}
      plugins={[circuitSolverPlugin, circuitReadoutsPlugin]}
    />
  );
}

That is the entire App.tsx for the circuit editor. Everything else in this writeup lives in the nodeTypes and plugins arrays.

Different built-in ways of data storing

Another thing that surprised me. Workflow Builder does not force any specific way of saving the diagram. There are 3 persistence strategies, picked via the integration prop on <WorkflowBuilder.Root />.

The first one is localStorage. This is the default, so if you do nothing you already have it. The SDK reads the diagram from localStorage when the editor mounts and writes it back when the user clicks Save (or when they close the tab, thanks to a beforeunload hook). Zero configuration, no backend, everything stays in the browser. Limitations are the obvious ones: data is per-browser and per-origin, capped around 5 MB.

The second one is REST API. You give the SDK 2 endpoints (one to GET the initial diagram from, one to POST the saved diagram to) and it handles the wiring for you.

The third one is callback (props strategy). You pass an onDataSave function and the SDK calls it whenever the diagram needs to persist. This is the escape hatch: if you need auth headers, custom error handling, file uploads, or any non-standard shape, this is the option that gives you full control.

For my one-day experiment I stayed with localStorage, but it is nice to know I will not have to rewrite anything when a real backend comes into the picture.

Let's build something

The starting point is a plain Vite + React app with @workflowbuilder/sdk installed and the snippet above as App.tsx. Standard commands:

pnpm i
pnpm dev

And the editor is up with the default (empty) diagram.

Tinker with the code

The first thing I wanted to modify is the node library. Based on the docs section on Node schemas, it looks like I just need to add a few schema files. Under src/feWorkflow Builder is great as a visualization tool and very generic, so iatures/workflowbuilder/nodes/ I added the nodes I needed for a simple circuit: Battery, Switch, Lightbulb, Ammeter, Voltmeter.

How I did it: the Battery example

For each node I created a folder with 4 files, following the canonical action example in the demo app. For Battery it looks like this.

battery/schema.ts describes the data the node holds:

import { sharedProperties, statusOptions } from '@workflowbuilder/sdk';
import type { NodeSchema } from '@workflowbuilder/sdk';

export const schema = {
  properties: {
    ...sharedProperties,
    status: { type: 'string', options: Object.values(statusOptions) },
    voltage: { type: 'number', minimum: 0 },
  },
} satisfies NodeSchema;

export type BatteryNodeSchema = typeof schema;

The sharedProperties spread gives me the standard label and description fields every node has, so I do not have to redeclare them.
Workflow Builder is great as a visualization tool and very generic, so i
battery/uischema.ts tells the SDK how to render the properties panel, in this case just a Text input for the voltage. battery/default-properties-data.ts holds the default values when the user drags a new Battery onto the canvas (I went with 9 V).

And finally battery/battery.ts ties everything together into a PaletteItem:

import type { PaletteItem } from '@workflowbuilder/sdk';

import { defaultPropertiesData } from './default-properties-data';
import { type BatteryNodeSchema, schema } from './schema';
import { uischema } from './uischema';

export const battery: PaletteItem<BatteryNodeSchema> = {
  type: 'battery',
  icon: 'BatteryFull',
  label: 'Battery',
  description: 'Power source providing voltage to the circuit.',
  defaultPropertiesData,
  schema,
  uischema,
};

The icon name (BatteryFull) is one of many ready-made icons exposed by the SDK – you reference them by string, no extra import needed. The last step is registering the node in src/features/workflowbuilder/palette.ts so it shows up in the left sidebar. That is the whole node. The other 3 (Switch, Lightbulb, Ammeter) follow exactly the same pattern.

Build the schema

Now I can see all the defined nodes in the palette:

I can drag and drop them onto the canvas and try to build something:

It is not interactive yet – this is only a visual presentation – but to this point it took me roughly 2 hours, including reading docs and writing this article, to get a working visualization. As I still had a lot of spare time, I figured I could try to make it more interactive. For example, when I turn off the switch, there should be no current and the bulb should stop glowing. The plugin API is well documented, so this should be doable.

The idea is crystallizing

I started with a simple lightbulb schema, but it looks like we can do a lot more. It should be possible to add some real logic and compare an LED bulb to a traditional one in terms of efficiency and cost. That is what I want to build.

Small adjustments

To make this work I added a few missing nodes. A Wattmeter to read the power going through a load. An Efficiency property on the Lightbulb (lumens per watt) so I can describe LED vs incandescent behavior. A Resistor so the circuit's total resistance is more than just the bulbs. And an Energy Stats node to show how much power and how much money the circuit costs over time.

Let's implement it

To make the circuit actually react to changes I wrote a small plugin called circuit-solver. The pattern is exactly what the docs describe. I registered a hook via the SDK plugin API (the OptionalHooks slot) that runs every time any node or edge in the diagram changes.

import { registerComponentDecorator } from '@workflowbuilder/sdk';

import { CircuitSolverRunner } from './circuit-solver-runner';

export function plugin(): void {
  registerComponentDecorator('OptionalHooks', {
    content: CircuitSolverRunner,
    name: 'CircuitSolver',
  });
}

The runner reads nodes and edges from the SDK store via useStore and runs a pure solver function. The solver walks the diagram starting from every Battery node, follows the outgoing edges around the loop, sums the resistances of every Resistor and Lightbulb it passes through (Lightbulb resistance is derived from V_nominal² / P_nominal), applies Ohm's law (I = V / R), and writes the resulting voltage, current and power back for every node in the loop. A Switch in the loop with isOn === false drops the current to zero everywhere.

The computed values land in a separate Zustand store. The readout plugin (which is the thing that paints the values directly on each node) just subscribes to that store. The solver stays pure, the readout stays React, and the two never collide. The whole solver fits in one file of around 250 lines.

One simplification: this only handles series circuits, one loop per battery, no branches. Parallel circuits and proper mesh analysis need Kirchhoff's laws, which is a much bigger task and not what I want to spend my one day on.

Now I need to draw the whole circuit:

It's alive!

When I turned the switch on, the logic from the plugin kicked in for all the new nodes and it looks like it is working correctly. The bulbs are shining and the Resistor value is taken into account. When I increase the resistance, the bulbs are barely glowing and the Energy Stats reacts:

Compare LED vs traditional bulb

To make a proper comparison I need two separate circuits and then I can check the Energy Stats node on each. Everything is customizable here, so you can easily adjust the electricity cost in your area and how many hours per day each bulb is on.

One small thing about the Energy Stats node. When I first built it, the cost was just a number with no currency unit, which on a diagram looks a bit weird. I went back and added a currency text field that defaults to $ but accepts anything: PLN, €, zł, whatever fits. It is a tiny change, but a nice example of how cheap adding a property is in this architecture. One new entry in the schema, one in the UI schema, one default value, and the readout picks it up.

Cost comparison

To compare costs properly I tuned the bulbs' nominal power so both produce the same brightness in lumens. To keep it realistic I aimed for 1000 lm, which is a moderate amount of light for a small room.

The focus now is on the Energy Stats nodes. About $20 per year for the traditional bulb running 5 hours a day, and only about $3 for the LED. That is roughly 7 times less cost for the same brightness. And that is one bulb.

Efficiency comparison

I already added the logic that makes a bulb dimmer when it runs below its rated voltage, so I can also check how efficient the LED is compared to the traditional bulb at the same power consumption.

Of course this is just a representation, real bulbs do not literally glow at these exact intensities, but Workflow Builder is flexible enough that I can adjust it for my needs. The point comes across: the LED produces much more visible light for the same wattage, while the Energy Stats confirms identical consumption.

Summary

Overall, a great experience

The architecture is generic enough to build well outside the workflow domain – this article is one example. An electrical circuit editor is about as far from a "workflow" as you can get, and I did not have to fight the SDK at any point. At the same time the genericity does not come at the cost of structure. There are clear patterns to follow (the 4-file node, the plugin decorators), so you are not dropped into a freeform mess. Without too much effort I was able to create proper node schemas to represent my needs.

The plugin API let me add domain-specific logic without touching the app core, which is a sign of good architecture. With more time I can imagine designing more nodes for other electrical devices and building a full home circuit that calculates how much power it draws.
Workflow Builder ships with a design system, including dark mode out of the box:

Idea for improvement

The default node template gives you one input on the left and one output on the right, which fits a workflow but not a symmetric domain like circuits, where a battery has + and -, a switch has two poles, and a resistor has two terminals. In this writeup I worked around it by placing nodes carefully on the canvas. The SDK has a proper way to do this: defineNodeTemplate lets you author a custom React component for a node type and declare whatever port topology you need, registered through the nodeTemplates prop on <WorkflowBuilder.Root />. A natural next step for this project would be a dedicated two-terminal template for the passive components so the wiring matches real schematics instead of relying on layout tricks.

FAQ

Is it possible to check the source code?

Yes, here are the links:

Can Workflow Builder be used for non-workflow domains?

Yes. The SDK is generic – nodes are described by JSON Schema and a UI schema, and plugins can react to any diagram change. The only constraint I hit was port topology (one input on the left, one output on the right), which is limiting for symmetric domains like electrical circuits.

How long does it take to add a new node type?

About 15-20 minutes per node once you know the pattern. Each node is 4 files (data schema, UI schema, default-properties, PaletteItem) plus 1 line in palette.ts to register it.

How does the plugin API work?

Plugins register decorators through registerComponentDecorator(slot, { content, name }). The slot tells the SDK where to mount your component – OptionalHooks runs every time nodes or edges change. From there you read the SDK store with useStore and write derived data back into your own Zustand store. The circuit-solver in this article fits in around 250 lines this way.

Which persistence strategies does Workflow Builder support?

3 strategies, picked via the integration prop on <WorkflowBuilder.Root />: localStorage (default, ~5 MB cap), REST API (you supply a GET and a POST endpoint), and props callback (you pass onDataSave and handle everything yourself).

Can Synergy Codes build a domain-specific editor like this?

Yes. Synergy Codes specializes in diagramming interfaces, workflow editors, and visualization tools, and has delivered 170+ custom editors for clients including Siemens, BMW, and Canon. Workflow Builder, ngDiagram, and Overflow are the open-source products we use as starting points – see synergycodes.com for case studies.

DEV Community: Workflow Builder