Key remapping via as: rename and filter keys in a mapped type

Renaming keys with as and template literals

When you need every key in a type to follow a naming convention — prefix with get, suffix with Changed, uppercase — you could write each one by hand. Or you can instruct the mapped type to compute the key instead of reuse it.

Since TS 4.1, a mapped type may add as <expr> after the in clause. For each K, the property is emitted under the key that <expr> resolves to, instead of under K itself. Combined with template literal types and the intrinsic Capitalize, this renames keys mechanically:

type Getters<T> = {
  [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K];
};

type State = { name: string; age: number };
type G = Getters<State>;
// ^? { getName: () => string; getAge: () => number }

Capitalize<"name"> is "Name" (an intrinsic string-manipulation type — unit 05’s template-literal lesson covers these in full), so the template `get${...}` yields "getName". The string & K intersection is load-bearing: keyof T can include number and symbol keys, but Capitalize only accepts string, so string & K narrows each key to its string part before interpolation.

Filtering keys: remap to never to delete them

Here is the move that makes remapping powerful. If the computed key is never, that property is omitted entirely. Pair this with a conditional on the value type and you get value-based filtering — no Pick/Omit key list required:

// Drop every property whose value is a function
type DataOnly<T> = {
  [K in keyof T as T[K] extends (...a: any[]) => any ? never : K]: T[K];
};

type Model = { id: number; name: string; save(): void; load(): void };
type D = DataOnly<Model>;
// ^? { id: number; name: string }   — save and load were remapped to never, dropped

The conditional runs per key: function-valued keys remap to never (and disappear), the rest remap to themselves (K) and survive. The inverse — keeping only keys whose value matches — just swaps the branches:

// Keep only keys whose value is a string (Pick-by-value-type)
type StringKeysOnly<T> = {
  [K in keyof T as T[K] extends string ? K : never]: T[K];
};

type R = StringKeysOnly<{ a: string; b: number; c: string }>;
// ^? { a: string; c: string }

Two constraints: legal key types, and lost homomorphism

The computed key must be assignable to PropertyKey — i.e. string | number | symbol. Remap to anything else (an object, a boolean) and TypeScript errors. That’s why renames go through template literals (which produce string keys) and filters go through never (the empty key).

Remapping also breaks homomorphism (last lesson): the moment you add as, the mapped type is no longer the bare { [K in keyof T]: ... } shape, so the link to the source is severed — modifiers like readonly/? are no longer auto-copied, and arrays/tuples won’t be preserved as containers. If you need both renaming and modifier preservation, you re-apply modifiers explicitly.

The cost side: a renamed key map is a maintenance liability

Key remapping is the most magical of the mapped-type tricks, and magic has a price. The first cost is invisible breakage: because as severs homomorphism, a Getters<T> silently drops the readonly and ? modifiers the source carried. A teammate who later marks a field readonly in the state type sees that constraint vanish from the generated setters — a real bug with no error. The second cost is navigability: getName exists nowhere in the source, so Find-References, grep, and a new reader’s mental model all miss it. The generated key is undebuggable by text search.

The senior breakpoint: remapping earns its place when the rename rule is genuinely uniform and the source set is open — deriving an event-handler interface from a props type, where adding a prop must add a handler automatically. It is the wrong tool the moment the key transform encodes business meaning that a reader needs to see, or the moment the source has only a handful of fixed fields. For value-based filtering specifically, weigh it against a runtime check: if the goal is to act on data-only fields at runtime, a plain Object.entries(...).filter(...) is legible and testable, where DataOnly<T> only shifts the discrimination to compile time and produces nothing at runtime. And when an external consumer (an SDK, a public API) needs these renamed shapes, a codegen step that writes out interface StoreActions { setName(v: string): void } as real source beats a remapped type the consumer cannot grep, hover cleanly, or extend — the generated .d.ts is an artifact; the as tower is a riddle.