Skip to main content

How Nuxt Board works

The complete mental model from application intent to rendered board.

Nuxt Board follows one direct flow:

application intent
  → engine command
  → validated transaction
  → canonical board state
  → subscriptions
  → Vue rendering

createBoardEngine() creates the source of truth. Application code changes it through commands. BoardRoot subscribes to the engine, renders effective state, and translates pointer and keyboard input through the framework adapter.

Four boundaries

  1. Commands own persistent mutation. Guards, validation, plugins, history, subscriptions, and events see the same commit.
  2. Session state stays transient. Drag and resize updates render immediately without rewriting the persisted document on every pointer move.
  3. Renderers own presentation. A renderer receives a node record. It does not create a competing state model.
  4. Packages own named capabilities. Core owns nodes; connections owns edges; history owns undo stacks; Nuxt owns registration.

Command inspector

Run one command and inspect the state change and publication order.

Try this Rename or move the selected card. The command commits before public events appear.

Run an action to inspect its publication order.

Before

{}

After

{}
Relevant code
engine.updateNode(card.id, {\n  text: 'Review onboarding · approved',\n  color: '4',\n})

Run a command in the lab. The document changes before queued public events publish. Subscribers never receive an intermediate candidate.

The engine is mutable internally so commands remain direct. Its public records and snapshots are immutable contracts. Keep the engine out of Vue deep reactivity; use a stable instance or shallowRef.