Generic Interfaces, Classes & Type Aliases

## The problem a generic declaration solves Without type parameters, a shape that wraps *some other type* has to be re-declared per payload: ```typescript interface UserResponse { data: User[]; status: number } interface OrderResponse { data: Order[]; status: number } ``` Every envelope field is now written twice, and adding `requestId` means editing every copy. A generic declaration parameterizes the varying slot instead of duplicating the fixed ones. ## Declaring the parameter ```typescript interface ApiResponse<T> { data: T; status: number; } ``` `<T>` after the name introduces a **type parameter**. It is an identifier that stands for a type not yet known, in exactly the way a function parameter stands for a value not yet known — which is why the analogy "generics are functions at the type level" is a fair one. The name is arbitrary; `T` is only convention, and `interface ApiResponse<Payload>` is equally valid and often clearer. ## What happens at the use site `ApiResponse` on its own is not a type you can annotate with — it is incomplete. You supply a **type argument** to finish it: ```typescript declare const res: ApiResponse<User[]>; res.data; // User[] res.data[0]; // User res.status; // number ``` The checker substitutes `User[]` for `T` throughout the body of the declaration. `ApiResponse<User[]>` and `ApiResponse<Order[]>` are two different types produced from one declaration; assigning one to a variable of the other is an error, because after substitution their `data` members have unrelated types. ## Where the parameter is in scope `T` is visible anywhere inside the declaration it belongs to — property types, method parameters, method return types, and nested positions: ```typescript interface Box<T> { value: T; items: T[]; map(fn: (v: T) => T): Box<T>; } ``` Note the last line: the declaration may mention itself with the same parameter, which is how container types describe operations that preserve their element type. `T` is *not* visible outside the declaration — there is no global `T` afterwards. ## The same mechanism on classes and aliases The parameter list is a property of the declaration, not of interfaces specifically. A class carries one the same way, and its members see it: ```typescript class Store<T> { private items: T[] = []; add(item: T): void { this.items.push(item); } } const s = new Store<string>(); ``` A type alias does too, and because an alias can name any type — not just an object shape — a parameterized alias can describe a union, a tuple or a function type: ```typescript type Result<T, E> = | { ok: true; value: T } | { ok: false; error: E }; ``` `Result<User, Error>` is that union with the substitutions applied. ## Nothing survives compilation An interface emits no JavaScript whatsoever, and neither do type arguments. `ApiResponse<User[]>` compiles to nothing; the emitted code just reads `res.data`. This has one consequence a candidate is expected to state out loud: annotating a value as `ApiResponse<User[]>` asserts a shape, it does not verify one. If the server returns `{ data: null }`, the type says `User[]` and the program crashes at the first `.length`. Validating an unknown payload — parsing it and narrowing — is a separate job the type layer does not do for you. ## Common confusions - **"T must be called T."** No — any identifier works, and descriptive names read better in public APIs. - **"The generic checks the data."** No — substitution happens in the checker; the runtime sees plain property access. - **"`ApiResponse<any>` is the same as `ApiResponse<User[]>`."** They are different types; the first has switched off checking of `data` entirely, which is usually the thing you were trying to avoid. ## What interviewers listen for That you can read the substitution mechanically ("`T` becomes `User[]`, so `data` is `User[]`"), that you name the parameter as belonging to the declaration rather than to any one use, and that you volunteer the erasure point without being pushed to it. Candidates who describe generics as "a way to accept any type" have described `any`; the point is that the *relationship* between `data` and the type argument is preserved.