In fragment colocation, what does a fragment's type condition bind a view to?

## `on` names a type in the schema A fragment definition carries a type condition - `fragment CourierCard_courier on Courier` - and that name must resolve to a composite output type in the schema. It is the only binding a fragment has. The fragment's *name* is a label unique within the document; the file it sits in, the view it was written for and the screen that spreads it are all invisible to the server. Everything colocation gets right, and everything it does not protect you from, follows from that one fact. ## The view is portable because the contract is a type Because the contract is `Courier`, the same colocated fragment travels to any position in any document whose parent field is a `Courier`: ```graphql fragment CourierCard_courier on Courier { displayName etaMinutes vehicle } query OrderTracking($orderId: ID!) { order(id: $orderId) { courier { ...CourierCard_courier } } } query DispatchBoard { onShiftCouriers { ...CourierCard_courier } } ``` One view, two screens, two parents, no edit. Renaming the view, moving its file, or wrapping it in another view changes none of this, because none of it was ever named in the document. This is the practical reason colocation survives refactoring where a hand-written screen query does not: the query encoded the screen's structure, the fragment encodes only a type. ## Reuse across different types is not free The flip side is exactly as sharp. A summary view asked to render an `Order` on one screen and a `PickupTicket` on another cannot spread a single fragment on `Order` in both places - the type condition would not be satisfiable where a `PickupTicket` is. The honest options are two fragments, one per type, or a fragment on an interface that both types implement. The second is a schema-design commitment: somebody must decide that `Order` and `PickupTicket` really are two kinds of one thing, name the interface, and put the shared fields on it. Reaching for the interface only because the UI happens to reuse a card is how a schema acquires abstractions that model the front end rather than the domain. Where a spread is legal at all - which type conditions may appear inside which selection sets - is a property of fragments generally rather than of colocation, and it is the reason the type condition is checked before anything executes. ## Read only what you declared The discipline that makes colocation more than a filing convention is that **a view reads only the fields its own fragment selected**, even when a sibling's fragment happened to fetch more onto the same object. Some client libraries enforce this by handing each view a masked view of the data; nothing in GraphQL does. If a status chip reads `placedAt` because the line-items fragment next door selected it, the chip breaks silently the day that other view is deleted - and the deletion looked completely safe, which is the whole point of colocation and exactly what the shortcut throws away. ## The binding is over fields, not values This is the limit worth being able to state. A colocated fragment fixes the *shape* of what arrives. It says nothing about the *domain* of the values. In one restaurant ordering graph, `OrderStatus` had five members and a status chip whose fragment selected `status` mapped each to a label and colour. A courier-assignment step shipped, and the enum gained `AWAITING_COURIER`. Nothing in the client changed: the fragment still selected `status`, the document still validated, the response still contained the field. The chip's mapping simply had no branch for the new member and fell through to an empty label - a blank chip on roughly 3.4% of live orders, unnoticed for eleven days because nothing anywhere threw. The lessons are two. First, treat every enum you select as **open**: always have a default branch, and render something honest for a value you do not recognise. Second, do not oversell colocation in an interview. It localises which fields a view depends on, and that is genuinely valuable; it cannot localise a dependency on the set of values a field may hold, on an argument's semantics, or on a nullable field starting to be null. Whether a schema may add an enum member at all, and with what notice, is a schema-evolution policy question, not something the document can express. ## Naming as a consequence The `Owner_propName` convention - `CourierCard_courier` - reads correctly once you see the type condition as the contract: the suffix names the value the view is handed, and the prefix keeps names unique in a document that may staple together fragments from a dozen files. If a view is handed two objects, it owns two fragments, one per type.