EEZ Studio Label IN and OUT: Preserve Flow-Local Routing During Refactoring

EEZ Studio Label IN and Label OUT can make a large Flow easier to read by replacing long visible connections with named routing. Their names are local routing references, not global message channels. Moving or copying a labeled branch into another Flow therefore deserves a connection audit, even if the names still look familiar.

The official Label IN documentation and Label OUT documentation describe connections within the same Flow, with multiple Label OUT components able to route to one Label IN. The pinned editor source looks for the corresponding Label IN among sibling components, reports a missing target and checks Label IN name uniqueness.

The implementation reference is EEZ Studio v0.29.0 at commit 3000161d09d40a5c1dc2477ddc30b38037b3a612. This discussion concerns standard Flow routing. It does not describe a cross-flow event bus or a User action call mechanism.

Inventory destinations before moving components

For a label named Finish, list the Label IN destination and every Label OUT that targets it. Then describe what arriving at Finish actually means. Is it normal completion, shared cleanup, cancellation or a display update? The name alone may not distinguish those purposes.

This inventory matters when several branches converge. Moving only one visible group can leave its Label OUT behind, or move an OUT into a Flow that contains a different same-named destination. A connection can be syntactically valid yet lead to a destination with the wrong business meaning.

Use names that communicate the routing role, but do not treat naming as a substitute for inspection. Two independently designed flows can both contain a perfectly reasonable label named Done and still have incompatible expectations about what happens there.

Check the new Flow boundary explicitly

When a branch moves to another Flow or User action, decide whether its old local destination should move with it. If the destination belongs to the caller, replace the local routing assumption with a documented cross-boundary interface appropriate to that design.

For a User action, that may involve explicit inputs, outputs and completion wiring. The exact interface should be reviewed according to the action's contract. Keeping the old label text does not preserve a connection to components outside the new Flow.

Do not invent a naming convention such as a path separator and assume it creates qualified cross-flow addressing. The cited label mechanism is local. A global-looking name remains a local name unless another documented feature supplies the wider routing behavior.

Use Check for structural errors, then test meaning

Run the project's structural checks after the move. A missing Label IN or duplicate local Label IN name is a useful, concrete error to resolve. Do not suppress it by creating an arbitrary target solely to make Check pass.

Once a target exists and names are unique, inspect its outgoing connections and side effects. Check cannot determine that a label named Cancel should skip a commit operation, or that a cleanup destination now clears the correct request state. Those are semantic requirements owned by the application.

A particularly useful negative test is a copied branch whose target label name already exists in the receiving Flow. Confirm that the branch reaches the intended destination, not simply whichever same-named route makes the diagram structurally complete.

Instrument each sender during refactoring

Temporarily give each Label OUT path a distinct diagnostic identity before it enters the shared destination. At Label IN's continuation, record that identity and the resulting action. Exercise every sender, including uncommon error and cancellation branches.

This is a proposed diagnostic method, not a built-in per-sender guarantee of the label feature. Preserve whatever data the application needs to identify the branch explicitly. A shared destination should not infer the sender from the last visible button or from unrelated global state.

If two senders can become active close together, observe both outcomes under the actual runtime. The label connection alone does not establish request serialization, cancellation or a merge policy. Those behaviors belong to the surrounding Flow design.

Review renames as connection changes

When a label is renamed, verify all intended local senders after the edit rather than assuming a particular automatic-rename behavior. The cited source establishes name lookup and validation, not every editor command's refactoring guarantees.

Keep the before-and-after sender inventory until the refactor is accepted. A route that disappeared entirely may not generate the same warning as a route with a misspelled target. Comparing the intended sender set helps catch accidental deletion as well as broken names.

No editor refactor or Flow execution was performed for this article. A successful acceptance test shows that every intended sender reaches the right local destination, no moved branch relies on an imaginary global channel, and the destination still performs the correct operation. That is the useful boundary between a cleaner diagram and a preserved control-flow contract.