Wiring Data & Flow

You make a wire by dragging from an output nub to an input nub - always from the right edge of one component to the left edge of another. Click and hold on the output, drag, and release on the target input. A curved wire appears, and data immediately begins to flow; the downstream component re-solves on the spot.

Several practical moves are worth knowing early. An output can feed many inputs - drag from the same output to several targets and it fans out; one slider can drive a dozen components. An input normally holds one wire: dragging a second wire to an occupied input replaces the first. To add a second wire into one input (combining sources), hold Shift while you release. To remove a wire, hold Ctrl and drag from the input as if disconnecting (on Mac, Command). And you can grab a wire's end and drag it to a new nub to rewire without deleting anything.

Grasshopper also stops you making nonsense connections. It will not let you wire an output to an output, or an input to an input; the shape of the interaction enforces 'output feeds input'. If a wire refuses to attach, you are usually aiming at the wrong side of a component.

Type compatibility is quietly forgiving here. Grasshopper will happily let a wire connect two nubs even when the types are not identical, then attempt a conversion on the fly - a number into a component expecting a curve fails and goes red, but a number into an input expecting a point, or an integer into a float input, often just works. That leniency is a feature: it means you rarely have to insert explicit converters, and it is why hovering a nub to learn its expected type matters, because the conversion the wire attempts depends entirely on that type. When a freshly made wire turns the target red, the very first thing to check is whether the data type you are supplying can sensibly become the type the input wants.

This is the law that governs the whole canvas: data flows in one direction, from outputs to inputs, and the graph can never loop back on itself. You cannot wire a component's output into anything that feeds it upstream - Grasshopper forbids the cycle. The result is what mathematicians call a directed acyclic graph, and it is precisely what lets the canvas re-solve predictably left to right, every time, as we saw in the canvas lesson.

Why does this matter to you as a designer? Because it means a definition always has a clear direction of cause. Every piece of geometry can be traced back, wire by wire, to the inputs that produced it - there is no hidden feedback, no 'which came first'. When something is wrong, you follow the wires upstream from the broken result until you find the block that went red or produced odd data. Debugging is literally walking against the flow.

It also means loops and feedback need special tools. Iterative processes - relaxing a mesh, growing a pattern, simulating physics - cannot be done with ordinary wires precisely because wires cannot cycle. That is exactly why plug-ins like Kangaroo (physics) and components like the data recorder exist: they package iteration safely so the main graph stays acyclic. You will meet Kangaroo in Module 7; for now, just trust the one-way rule.

The one-way flow has one more happy consequence: the wire is the documentation. Because every dependency in a definition is a visible wire pointing from cause to effect, a reader can reconstruct the entire logic just by following the strands, without any hidden state or side effects to worry about. This is a real advantage over text code, where a variable can be changed from anywhere. In Grasshopper, if a value reaches a component, there is a literal wire you can trace back to its source. That visible, traceable causality is a big part of why the visual approach is so learnable - and why keeping your wiring tidy, the subject of the last section, is not just neatness but readability.

Here is a detail that turns you from novice to fluent: the appearance of a wire tells you the shape of the data inside it, before you open a single Panel. Grasshopper draws wires in three styles based on the data structure they carry.

A faint, thin (often dashed) wire carries a single item - one number, one point, one curve - or is empty. A normal solid line carries a list of items - many points, a set of curves. A bold, double line carries a data tree: a list-of-lists organised into branches, the structured data we tackle in Module 3. So at a glance across a busy canvas you can tell that this wire holds one value, that one holds a list, and the bold one holds a tree - which is enormously useful, because most beginner bugs are really 'my data is the wrong shape' problems.

You can turn these display styles on explicitly (right-click canvas > Draw Fancy Wires) and you can also change how a specific input renders its incoming wires. Reading wire weight becomes second nature fast, and it saves you from constantly dropping Panels to check structure. When a downstream component misbehaves, glance at the incoming wire: a bold wire arriving where the component expected a single item is a classic, instantly-spotted cause.

Why does data shape matter so much? Because Grasshopper's behaviour changes with it. A component fed a single item runs once; fed a list, it runs once per item; fed a tree, it runs per branch and keeps the branches separate. So the very same wiring produces wildly different results depending only on whether the data is one item, a list, or a tree - and the wire's weight is your early warning of which case you are in. This is the doorway to Module 3, the make-or-break topic of the whole tool. For now, the takeaway is modest but powerful: learn to see wire weight, and you can predict how a component will behave before it even runs.

Definitions grow, and messy wiring is the fastest way to a canvas you cannot read. A few habits keep the flow legible. Rewire by dragging wire ends rather than deleting and re-drawing - you keep the rest intact. Use the input's right-click to disconnect cleanly when you need to. And lay components out roughly left to right in the order data flows, so the graph physically mirrors its logic; a definition that reads left-to-right on screen is one you can debug months later.

When wires cross into spaghetti, Grasshopper offers relief. You can hide a wire's visible path by setting an input's wire display to hidden, keeping the connection but decluttering. Better, you can insert data-passing shortcuts: components or scribbles that carry data across the canvas without a long visible wire. But do not over-hide - a wire you cannot see is a dependency you can forget, which is its own kind of bug.

The deeper point is that wiring is where your logic becomes visible, so treat it as communication, not just connection. A tidy, left-to-right, well-grouped definition is readable by a collaborator - or by you next year. That readability is not cosmetic; in a professional setting a definition nobody can follow is a liability, however clever it is. In the next lesson we put all of this together and build a real, tidy definition end to end.