Architecture
One AV Device, Three Views: Why Shared Identity Matters
By Vivek Jalondhara · 5 min read
Published
Separate equipment identity from its floor-plan, rack, and signal-diagram placements so edits and engineering documents stay coherent.
An amplifier appears on a floor plan, occupies space in a rack drawing, and has connections in a signal diagram. Those are three representations of one physical device. If each view stores an independent device copy, a label change becomes three edits and an equipment list can accidentally count the same item three times.
The AV Design and Engineering Suite case study describes shared equipment across these views. The following educational model examines the consequences of that idea. Its identifiers and operations illustrate the domain rather than disclose the project’s private schema.
Give equipment and placement different identities
Equipment identity answers which physical device the design refers to. Placement identity answers where a representation appears on a particular drawing. A device can therefore have several placements without becoming several devices. A placement can move without changing the equipment’s identity.
A React Flow node also needs an identity within its rendered graph. Using the placement identifier for that node leaves the equipment identifier available as a separate reference. This distinction becomes important when the same device appears twice on one sheet, for example as a detailed view and a contextual reference.
Assign each attribute to the right owner
A model number or equipment label normally belongs to the equipment record. A symbol’s position, rotation, and sheet belong to its placement. Physical rack occupancy may need its own domain representation because it is more than a visual coordinate. Decide those meanings before choosing convenient component props.
Copying the label into every placement appears convenient for rendering, but introduces an update obligation. Deriving the displayed label from the equipment record avoids that duplication. If a drawing intentionally overrides the label, represent an explicit override so a reader can distinguish customization from stale data.
Separate a port connection from its drawing
A logical connection identifies equipment ports, while an edge on a sheet identifies how that connection is shown. React Flow handles provide connection points and handle identifiers for rendering, but the application still defines the corresponding equipment-port identity and compatibility rules.
Consider moving a signal representation to another sheet. Its node identifier or position may change, while the underlying cable connection remains the same. Binding the only connection record to one visual node pair makes rearranging documentation look like rewiring the installation.
Make deletion and duplication explicit operations
Removing a floor-plan symbol should not automatically delete the physical device from the project. Deleting the equipment itself may affect its rack placement, signal references, and connected cables. These actions deserve distinct commands with visible consequences.
Duplication has the same ambiguity. “Show this device on another sheet” creates a placement that references existing equipment. “Add another amplifier of this model” creates new equipment and then a placement. Reusing one generic copy handler can produce either duplicate counts or unintended shared edits depending on which identity it copies.
Generate documents from one coherent snapshot
An equipment list should follow the project’s equipment and quantity policy, including devices that have not yet been placed. Counting visible nodes is only correct if the product deliberately guarantees one node per counted device. That guarantee does not hold in this three-view scenario.
Exports also need a consistent revision. A floor-plan image produced before a rename and a cable schedule produced afterward can disagree despite a normalised data model. Capture or request a coherent project snapshot for a document set, and make missing equipment references an explicit validation failure instead of silently dropping them.
Use invariants to evaluate the model
Rename one device and check every derived view. Move its rack symbol and verify that its signal connections do not change. Remove one placement and confirm that equipment and other placements remain. Duplicate a physical device and verify that editing the new device does not rename the original.
These checks explain the value of shared identity more clearly than a diagram of tables alone. The tradeoff is extra lookup and validation work at boundaries. That work is visible and testable, whereas synchronizing independent copies leaves correctness dependent on every editing path remembering every other view.
Derive placement labels from shared equipment
This small projection rejects a dangling reference. It intentionally omits drawing coordinates and port connections so the equipment-to-placement relationship remains clear.
Illustrative example · TypeScript · Simplified for explanation
type Equipment = { id: string; label: string; model: string };
type Placement = {
id: string;
equipmentId: string;
view: "floor" | "rack" | "signal";
};
function describePlacement(
placement: Placement,
equipment: ReadonlyMap<string, Equipment>
) {
const device = equipment.get(placement.equipmentId);
if (!device) throw new Error("Placement references missing equipment");
return {
placementId: placement.id,
equipmentId: device.id,
view: placement.view,
label: device.label,
};
}- Create one equipment identity
- Reference it from separate placements
- Derive each view from shared attributes
- Generate documents from a consistent revision
Conceptual flow for the example above.
Tradeoff to keep in mind
Shared identity requires deliberate deletion and reference validation. It removes the need to synchronise copied equipment attributes, but does not remove genuinely different state owned by each view.