Lesson 23 of 80

Decorators

Q: What is a decorator, and how does it relate to the higher-order-function/HOC pattern you've seen elsewhere?

A strong answer covers: A decorator is a function that wraps/enhances a class, method, or property, applied declaratively via @ syntax; Structurally identical to a higher-order function/HOC: takes something, returns an enhanced version; A decorator factory is a function returning a decorator, enabling configuration to be passed in.

A function that wraps a class or its members to add behavior declaratively — the higher-order-function idea again, this time expressed as an annotation instead of an explicit wrapping call.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

Structurally, what does `@logged` on a class method have in common with a React Higher-Order Component?

Nothing — decorators and HOCs solve completely unrelated problemsBoth wrap something (a method / a component) with a function that returns an enhanced version of itBoth only work with class components, never function components

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Decorators

What interviewers actually ask about this, and what a strong answer has to cover.

What is a decorator, and how does it relate to the higher-order-function/HOC pattern you've seen elsewhere?

A strong answer covers

A decorator is a function that wraps/enhances a class, method, or property, applied declaratively via @ syntax
Structurally identical to a higher-order function/HOC: takes something, returns an enhanced version
A decorator factory is a function returning a decorator, enabling configuration to be passed in

Likely follow-ups

What frameworks make heavy use of decorators, and for what purpose?
What's the difference between the older experimentalDecorators proposal and the newer standardized one, at a high level?
If you apply two decorators to the same method, what determines the order they run in?

Practice these with the AI interviewer →

The plain-language idea

function logged(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
  const original = descriptor.value;
  descriptor.value = function (...args: any[]) {
    console.log(`Calling ${propertyKey}`);
    return original.apply(this, args);
  };
}

class Service {
  @logged
  fetchData() { /* ... */ }
}

@logged is sugar for "wrap fetchData with the logged function" — structurally, this is the exact same idea as a Higher-Order Component or a withUser-style HOC from the React track: a function that takes something (here, a method) and returns an enhanced version of it. The @ syntax just lets you apply that wrapping declaratively, right where the method is defined, instead of calling a wrapper function separately afterward.

Decorators: wrapping the class definition, not its instancesStep 1 of 3

@logged class ApiClient { ... } — a function that wraps a class definition.

What people usually miss

Watch out

Decorators need experimentalDecorators (the older stage-2 proposal TypeScript has long supported) or targeting a recent enough spec for the newer, now-standardized decorators proposal — the two versions have real syntax and behavior differences, and mixing assumptions between them is a common source of confusion.
A decorator can be a decorator factory — a function that returns a decorator, letting you pass configuration: @Column({ nullable: true }) is calling Column(...), which itself returns the actual decorator function applied to the property.
Multiple decorators on one target apply like nested function calls, bottom to top for evaluation order in some cases — order matters, and getting it backwards is a real, subtle bug source in decorator-heavy codebases.

Why this matters in interviews

If you've worked with Angular, NestJS, or TypeORM, decorators come up constantly — recognizing them as "a higher-order function applied via declarative syntax" rather than mysterious framework magic is what separates using them from actually understanding them.