What Are Interactive Components and How Do You Build Them on a Canvas?

Updated

Interactive components are the reusable building blocks of a canvas-based visual program: self-contained pieces you place on an infinite canvas, configure, and wire together so they respond to input and pass data or trigger behavior. On tldraw's computer (computer.tldraw.com), you build them visually rather than by writing a full application, and the site describes the workflow as creating visual programs, connecting components, and using AI to power what you make. The main condition to know up front: the tool runs in the browser and requires JavaScript to be enabled, so a page that stays blank usually means scripting is blocked rather than the canvas being empty.

Static shapes vs. interactive components

The distinction matters because both live on the same canvas and look similar at a glance.

Static shape Interactive component
Responds to input No Yes
Holds state or logic No Yes
Can be connected to others Rarely meaningful Designed for it
Role in a program Annotation, layout, reference Functional unit of the program

A drawn rectangle is a shape. A component that reads a value, changes when you interact with it, or feeds another component is part of the program's behavior. If nothing on your canvas reacts when you click, drag, or change a value, you are most likely working with static shapes rather than components.

How components are placed, configured, and connected

The general pattern in canvas-based visual programming, and the one the site's description points to, is:

  1. Place a component on the canvas. It becomes an object with its own position and identity.
  2. Configure it. Components expose settings or inputs that determine what they do — a source of data, a condition, a display format.
  3. Connect it. Wiring one component's output to another's input is what turns a collection of parts into a working program.
  4. Run and observe. Because the canvas is live, you see the result of the connections rather than compiling and launching separately.

The connection step is the one that carries the most meaning. A wire is a claim that "this output feeds that input," so a program that does nothing is often a program whose wires are missing, reversed, or pointing at the wrong port.

Wiring components to pass data or trigger behavior

Two broad kinds of connection show up in node-based editors, and it helps to know which one you are making:

  • Data flow — a value produced by one component becomes the input of another. Change the source and everything downstream updates.
  • Trigger or event flow — one component's action causes another to run. The connection carries "when this happens, do that" rather than a value.

If a component receives data but never appears to act, check whether you wired a data connection where a trigger was needed, or the reverse. They are not interchangeable.

Where AI fits

The site lists AI as a way to power your creations, which in practice means AI can generate or drive component behavior instead of you specifying every rule by hand. Treat this as an accelerator for the parts that are tedious to encode manually, and keep the deterministic wiring — what connects to what — under your own control so you can still reason about why the program behaves as it does.

When components don't respond

Work through these in order, since each rules out a different layer:

  • Blank canvas or nothing loads — JavaScript is disabled or blocked. The site states plainly that JavaScript must be enabled to run tldraw.
  • The component renders but ignores clicks — you may have a static shape, not an interactive component.
  • It reacts but nothing downstream changes — the output is not wired to the next component's input, or the wire is on the wrong port.
  • It worked, then stopped — an upstream value or trigger changed. Trace back along the connections to the first component that no longer produces what the rest expect.
  • Behavior is unpredictable — too much logic is hidden inside AI-driven parts. Move the connection structure back into explicit wiring so each step is inspectable.

The reliable habit is to test one connection at a time: place two components, wire them, confirm the second responds to the first, then add the next. Debugging a canvas is much easier when you know which wire introduced the problem.