In a .tsx file, `const identity = <T>(value: T) => value;` fails to compile although the identical line is fine in a .ts file. Why, and what are two ways to write it so it parses?

## Two grammars competing for one character TypeScript reuses `<` and `>` for two unrelated things: type parameter and type argument lists, and — when JSX is enabled — element tags. In a `.ts` file only the first meaning exists, so `<T>(value: T) => value` is unambiguously a generic arrow function. In a `.tsx` file the parser sees `<` in expression position and takes the JSX branch: `T` becomes a tag name, `(value: T) => value` becomes children, and the file ends without a closing `</T>`. The error you get is about JSX, which is why it reads as nonsense to someone who thinks they wrote a generics problem. This is a pure *parsing* rule. Nothing about generic arrow functions is restricted in `.tsx`; you only have to write them in a form the parser cannot mistake for markup. ## The three forms that work ```typescript // 1) trailing comma: a tag name cannot be followed by a comma const identity = <T,>(value: T) => value; // 2) a constraint: `extends` cannot appear in a tag const first = <T extends unknown>(items: T[]): T | undefined => items[0]; // 3) function syntax: the name comes before the angle brackets function last<T>(items: T[]): T | undefined { return items[items.length - 1]; } ``` The trailing comma is the most common in modern codebases because it is minimal and says nothing false about the type. The `extends unknown` form is the older idiom and is equivalent in meaning — `unknown` is the top type, so it constrains nothing — but readers sometimes mistake it for a deliberate bound. A real constraint (`<T extends object>`) also disambiguates, but pick it because the code needs the bound, not to satisfy the parser. Function declarations and function expressions sidestep the issue entirely, which is one reason many teams write generic components as `function` declarations by default. ## The same rule, elsewhere The angle brackets are contested in one more place. TypeScript has two assertion syntaxes: ```typescript const a = value as string; // works everywhere // const b = <string>value; // parse error in .tsx: reads as a JSX tag ``` So `.tsx` files must use `as`. This is worth knowing as the same phenomenon rather than a separate rule: JSX has taken the angle brackets, and every construct that wanted them needs another spelling. Since `as` works in `.ts` too, most style guides simply ban the angle-bracket form outright. Type *arguments* at a call site are not affected — `identity<string>("x")` parses fine in `.tsx`, because the `<` follows an expression rather than opening one. The ambiguity only exists where an expression begins. ## Where it bites in practice The rule shows up the moment someone writes a generic component or hook as an arrow constant, which is the dominant style in many frontend codebases: ```typescript type Props<T> = { items: readonly T[]; renderItem: (item: T) => string }; const List = <T,>({ items, renderItem }: Props<T>): string => items.map(renderItem).join(""); ``` Without the comma this is a wall of JSX errors, and formatters occasionally strip a lone trailing comma if they are configured for a non-TSX parser — a recurring source of "it compiled yesterday" confusion. When that happens, converting to `function` syntax is the durable fix rather than fighting the formatter. ## What interviewers are checking This is a recall question with a short right answer, and the failure mode is a candidate who invents a semantic explanation — "arrow functions can't be generic", "you need a constraint under strict mode", "JSX erases type parameters". None of those are true. The expected answer is one sentence about the parser plus at least one working spelling, and a strong candidate adds that this is the same reason `as` is mandatory for assertions in `.tsx`.