TypeScript Utility Types Every Angular Developer Should Know

Ojas Deshpande — Mon, 06 Apr 2026 13:51:23 +0000

Introduction

TypeScript ships with a set of built-in generic types called utility types. They transform existing types into new ones — making properties optional, readonly, or required; picking or omitting specific keys; extracting return types from functions. They let you express complex type relationships without duplicating type definitions.

Most Angular developers use a handful of them — Partial and Observable come to mind — but the full set is underused relative to how much it can simplify type-heavy Angular code. This article covers the utility types that appear most frequently in Angular applications, with concrete examples drawn from the patterns you encounter every day: form handling, HTTP services, component inputs, NgRx state, and API response modeling.

Partial

Partial<T> makes all properties of T optional. Every property becomes T[key] | undefined.

The most common Angular use case is update payloads. When patching a resource, you only send the fields that changed — not the entire object.

interface User {
  id: string;
  name: string;
  email: string;
  role: 'admin' | 'viewer';
  lastLogin: Date;
}

@Injectable({ providedIn: 'root' })
export class UserService {
  updateUser(id: string, changes: Partial<User>): Observable<User> {
    return this.http.patch<User>(`/api/users/${id}`, changes);
  }
}

// Caller only provides what changed — TypeScript enforces this
this.userService.updateUser(userId, { name: 'Jane', role: 'admin' });

Partial also appears in form state modeling. A form in progress may not have all fields populated yet:

interface ProductForm {
  name: string;
  price: number;
  description: "string;"
  category: string;
}

// Form state before the user has filled everything in
type DraftProduct = Partial<ProductForm>;

// TypeScript won't complain about missing fields
const draft: DraftProduct = { name: 'Widget' };

Required

Required<T> is the inverse of Partial — it makes all optional properties required. This is useful when you've modeled something with optional fields during construction but need to assert that all fields are present at a later stage.

interface Config {
  apiUrl?: string;
  timeout?: number;
  retries?: number;
}

function validateConfig(config: Config): Required<Config> {
  if (!config.apiUrl) throw new Error('apiUrl is required');
  if (!config.timeout) throw new Error('timeout is required');
  if (!config.retries) throw new Error('retries is required');

  // After validation, we assert the config is fully populated
  return config as Required<Config>;
}

// From this point on, TypeScript knows all fields are defined
const validated = validateConfig(rawConfig);
console.log(validated.apiUrl); // string, not string | undefined

Readonly

Readonly<T> makes all properties of T non-writable. Attempts to mutate properties on a Readonly<T> type fail at compile time.

In Angular applications with OnPush change detection, immutability is the contract that makes the strategy work correctly. Readonly<T> lets you enforce this at the type level rather than just by convention:

interface AppState {
  users: User[];
  selectedUserId: string | null;
  isLoading: boolean;
}

// State is never mutated — only replaced
type ImmutableState = Readonly<AppState>;

function reducer(state: ImmutableState, action: Action): ImmutableState {
  switch (action.type) {
    case 'SET_LOADING':
      // Return new object — cannot mutate state directly
      return { ...state, isLoading: action.payload };
    default:
      return state;
  }
}

For deeply nested immutability, Readonly<T> only applies at the top level — nested objects remain mutable. For deep immutability, use ReadonlyArray<T> for arrays and recursive Readonly wrappers, or a library like immer.

Pick

Pick<T, K> creates a new type containing only the properties of T whose keys are in the union K.

The most valuable Angular use case is creating view models from full entity types. Your API returns a rich User object, but a particular component only needs three fields:

interface User {
  id: string;
  name: string;
  email: string;
  role: 'admin' | 'viewer';
  createdAt: Date;
  lastLogin: Date;
  preferences: UserPreferences;
  address: Address;
}

// The user card only needs these three fields
type UserCardViewModel = Pick<User, 'id' | 'name' | 'email'>;

@Component({
  selector: 'app-user-card',
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class UserCardComponent {
  @Input() user!: UserCardViewModel;
  // Component can't accidentally access fields it shouldn't need
}

This pattern enforces component encapsulation at the type level. A component that displays a user card has no business accessing preferences or address. Pick makes that boundary explicit and compiler-enforced.

Omit

Omit<T, K> is the complement of Pick — it creates a type containing all properties of T except those in K.

The canonical Angular use case is create payloads. When creating a new resource, server-generated fields like id and createdAt don't exist yet:

interface User {
  id: string;
  name: string;
  email: string;
  role: 'admin' | 'viewer';
  createdAt: Date;
}

// For creation, id and createdAt are server-generated
type CreateUserPayload = Omit<User, 'id' | 'createdAt'>;

@Injectable({ providedIn: 'root' })
export class UserService {
  createUser(payload: CreateUserPayload): Observable<User> {
    return this.http.post<User>('/api/users', payload);
  }
}

// TypeScript error if you try to pass id in the payload
this.userService.createUser({
  name: 'Jane',
  email: 'jane@example.com',
  role: 'viewer'
  // id: '...' — TypeScript error: Object literal may only specify known properties
});

Record

Record<K, V> creates a type representing an object whose keys are of type K and whose values are of type V. It's the typed alternative to { [key: string]: V }.

In Angular applications, Record is useful for lookup tables, state maps, and any dictionary-style structure:

type UserId = string;
type LoadingState = 'idle' | 'loading' | 'success' | 'error';

// Track loading state per entity ID
type EntityLoadingMap = Record<UserId, LoadingState>;

// In an NgRx reducer or component state
interface UserState {
  entities: Record<UserId, User>;
  loadingStates: Record<UserId, LoadingState>;
  selectedId: UserId | null;
}

Record with a union key type is particularly powerful — it constrains the valid keys to only the members of the union:

type Route = 'home' | 'products' | 'orders' | 'settings';
type RoutePermissions = Record<Route, boolean>;

const permissions: RoutePermissions = {
  home: true,
  products: true,
  orders: false,
  settings: false,
  // TypeScript error if any Route key is missing
  // TypeScript error if any key outside Route is added
};

ReturnType

ReturnType<T> extracts the return type of a function type T. This is most useful when you want to derive a type from a function's output without declaring the type separately.

In Angular, this pattern appears most clearly with factory functions and NgRx selectors:

// A factory function that builds a complex object
function createUserViewModel(user: User, permissions: Permissions) {
  return {
    id: user.id,
    displayName: `${user.name} (${user.role})`,
    canEdit: permissions.includes('user:edit'),
    canDelete: permissions.includes('user:delete'),
  };
}

// Derive the type from the function without duplicating it
type UserViewModel = ReturnType<typeof createUserViewModel>;

// Now use it as an @Input type
@Component({ ... })
export class UserDetailComponent {
  @Input() viewModel!: UserViewModel;
}

With NgRx selectors:

export const selectUserViewModel = createSelector(
  selectCurrentUser,
  selectPermissions,
  (user, permissions) => ({
    id: user.id,
    displayName: user.name,
    canEdit: permissions.canEditUsers,
  })
);

// Derive the output type from the selector
type UserViewModelState = ReturnType<typeof selectUserViewModel>;

Parameters

Parameters<T> extracts the parameter types of a function as a tuple. Less commonly used than ReturnType, but valuable when you need to pass or store function arguments as typed values.

function searchUsers(
  query: string,
  filters: UserFilters,
  pagination: PaginationOptions
): Observable<PaginatedResult<User>> {
  return this.http.get<PaginatedResult<User>>('/api/users', {
    params: buildQueryParams(query, filters, pagination)
  });
}

// Extract parameter types without re-declaring them
type SearchParams = Parameters<typeof searchUsers>;
// SearchParams is [string, UserFilters, PaginationOptions]

// Useful for caching search arguments
function cacheSearch(params: SearchParams): void {
  const [query, filters, pagination] = params;
  // ...
}

NonNullable

NonNullable<T> removes null and undefined from a type union. Useful after null checks when you need to assert to TypeScript that a value is definitely present:

interface RouteData {
  userId: string | null;
  productId: string | undefined;
}

function processRoute(data: RouteData) {
  if (!data.userId) throw new Error('userId required');

  // Without NonNullable, TypeScript still thinks userId could be null here
  // because it doesn't narrow across function calls
  const userId: NonNullable<typeof data.userId> = data.userId;
  // userId is now typed as string
}

A more practical Angular pattern — using NonNullable with the async pipe and strict null checks:

@Component({
  template: `
    @if (user$ | async; as user) {
      <!-- Inside this block, user is NonNullable -->
      <app-user-card [user]="user" />
    }
  `
})
export class UserPageComponent {
  user$: Observable<User | null> = this.store.select(selectCurrentUser);
}

Extract and Exclude

Extract<T, U> extracts from T the types that are assignable to U. Exclude<T, U> does the opposite — it removes from T the types assignable to U.

These are most useful with union types:

type Status = 'idle' | 'loading' | 'success' | 'error';

// Only the terminal states (not loading or idle)
type TerminalStatus = Extract<Status, 'success' | 'error'>;
// TerminalStatus = 'success' | 'error'

// Everything except loading
type NonLoadingStatus = Exclude<Status, 'loading'>;
// NonLoadingStatus = 'idle' | 'success' | 'error'

In Angular applications, this pattern is valuable for narrowing action types in effects or reducers:

type UserAction =
  | { type: 'LOAD_USER'; id: string }
  | { type: 'LOAD_USER_SUCCESS'; user: User }
  | { type: 'LOAD_USER_FAILURE'; error: string }
  | { type: 'UPDATE_USER'; changes: Partial<User> }
  | { type: 'DELETE_USER'; id: string };

// Only the actions that affect loading state
type LoadingActions = Extract<
  UserAction,
  { type: 'LOAD_USER' | 'LOAD_USER_SUCCESS' | 'LOAD_USER_FAILURE' }
>;

Combining Utility Types

The real power comes from composing utility types. A few patterns that appear frequently in production Angular codebases:

Create vs Update payloads from a single interface:

interface Product {
  id: string;
  name: string;
  price: number;
  categoryId: string;
  createdAt: Date;
  updatedAt: Date;
}

type CreateProductPayload = Omit<Product, 'id' | 'createdAt' | 'updatedAt'>;
type UpdateProductPayload = Partial<Omit<Product, 'id' | 'createdAt' | 'updatedAt'>>;

Safe subset for a component input:

// Only expose the fields a display component needs, as readonly
type ProductCardInput = Readonly<Pick<Product, 'id' | 'name' | 'price'>>;

Discriminated union response type:

type ApiResponse<T> =
  | { status: 'success'; data: T }
  | { status: 'error'; message: string }
  | { status: 'loading' };

type SuccessResponse<T> = Extract<ApiResponse<T>, { status: 'success' }>;
// SuccessResponse<T> = { status: 'success'; data: T }

Conclusion

TypeScript's built-in utility types are the vocabulary of type-level programming in Angular. They let you express the relationships between your types — between a full entity and its create payload, between a rich API response and the view model a component needs, between a union of all possible states and the subset a particular handler cares about — without duplicating type definitions.

The individual types are each simple. The discipline of reaching for them consistently — instead of writing any, loosening types, or duplicating interfaces — is what makes a large TypeScript codebase maintainable. Each utility type usage is a constraint you're encoding once and getting for free everywhere the type is used.

DEV Community: Ojas Deshpande