Class Features — Private Fields, Static Blocks, Decorators

Modern class features added since ES2022: #private fields (real privacy enforced by the engine, not convention), static blocks (static { ... } for one-time init in a class body), and decorators (Stage 3, @decorator syntax for class/method/field meta-programming). All three are now in TC39 Stage 4 or near-final. The big mental shift: #x is real privacy — not the TypeScript private keyword, which only prevents TS errors and is ignored at runtime.

#private vs TypeScript private — what’s the difference?

class Cat {
  private name = "Felix";        // TS-private
  #age = 3;                       // truly private
}

const c = new Cat();
// In .ts: c.name → TS error, but at runtime it works (c["name"] returns "Felix")
// c.#age → SyntaxError at parse: "Private field '#age' must be declared in an enclosing class"

For real privacy (other JS code can’t access), use #. TS private is a hint; JS engines don’t enforce it.

Show me #private features.

class BankAccount {
  #balance: number;
  static #nextId = 1;             // private static
  #id: number;

  constructor(balance: number) {
    this.#balance = balance;
    this.#id = BankAccount.#nextId++;
  }

  deposit(n: number) { this.#balance += n; }
  get balance() { return this.#balance; }

  // Private method
  #computeInterest() { return this.#balance * 0.05; }

  applyInterest() { this.#balance += this.#computeInterest(); }
}

All # members: private fields, private methods, private static fields, private static methods, private getters/setters. Real privacy.

#in check — does this object have the private field?

class Animal {
  #name = "x";

  static isAnimal(obj: unknown): obj is Animal {
    return typeof obj === "object" && obj !== null && #name in obj;
  }
}

console.log(Animal.isAnimal(new Animal())); // true
console.log(Animal.isAnimal({}));            // false

#x in obj is the “brand check” — confirms an object is a real instance of the class (not a duck-typed lookalike). Useful for runtime type discrimination.

Static initialization blocks — what’s the use?

Initialize static state that needs control flow (try/catch, loops, async-light setup):

class Config {
  static #data: Record<string, unknown>;

  static {
    try {
      Config.#data = JSON.parse(globalThis.__INITIAL_CONFIG__ ?? "{}");
    } catch (e) {
      console.error("bad config", e);
      Config.#data = {};
    }
    if (!Config.#data.timeout) Config.#data.timeout = 30_000;
  }

  static get(key: string) { return Config.#data[key]; }
}

Runs once when the class is defined. Cleaner than module-level IIFE for class-scoped init.

Multiple static {} blocks are allowed; they run in source order.

Decorators — what stage are we at?

Stage 3 at TC39; specced, implemented by TypeScript 5.0+, supported by SWC and Babel, available in modern Node and bundlers. Different from the legacy TS experimental decorators (experimentalDecorators: true) — the new spec is its own thing.

Decorator syntax — show me.

function logged<T extends new (...args: any[]) => any>(target: T, ctx: ClassDecoratorContext) {
  ctx.addInitializer(function () {
    console.log(`Created ${ctx.name}`);
  });
  return target;
}

function bound(target: Function, ctx: ClassMethodDecoratorContext) {
  return function (this: any, ...args: any[]) {
    return target.apply(this, args);
  };
}

@logged
class Widget {
  @bound
  handleClick() { console.log("clicked"); }
}

Decorators receive:

• The target (class, method, field, accessor, getter, setter).
• A context object with kind, name, addInitializer, private flag, etc.

Use cases:

• Method binding (@bound to auto-bind this).
• Logging / instrumentation (@deprecated, @logged).
• Memoization (@memoized).
• Framework integration (Angular components, MobX @observable, NestJS controllers).

Are decorators worth using now?

Yes for new code in supportive ecosystems (Angular, NestJS, MobX, LitElement). Cautious for general TS apps — debugging and tooling around decorators is still maturing.

The legacy experimental decorators (still common in Angular, NestJS) are different syntax + semantics. Migration to stage-3 decorators is in progress for many frameworks.

If you’re writing a library that exposes decorators: use stage-3 syntax (tsconfig without experimentalDecorators). If you’re maintaining legacy code with @injectable, stay on the old spec until the framework upgrades.

Auto-accessors — what?

A stage-3 sibling of decorators: declare a field as auto-accessor (accessor keyword) so decorators can intercept reads/writes:

function debounced<T>(ms: number) {
  return function (target: ClassAccessorDecoratorTarget<unknown, T>, ctx: ClassAccessorDecoratorContext) {
    let timer: any;
    return {
      get() { return target.get.call(this); },
      set(value: T) {
        clearTimeout(timer);
        timer = setTimeout(() => target.set.call(this, value), ms);
      },
    };
  };
}

class Search {
  @debounced(300) accessor query = "";
}

accessor query = "" desugars to a private field + get/set. Useful for reactive frameworks adopting decorators.

Why use classes at all in modern React/Vue?

Increasingly rare. React abandoned class components for hooks; Vue’s Options API still uses class-like structure but moved to Composition API. Classes still fit for:

• Domain models (User, Order, Cart) — clearer than nested objects for behavior + state.
• Service classes (ApiClient, EventBus, Logger) — singleton-style.
• Error subclasses — class NetworkError extends Error { constructor(...) { ... } }.
• Framework integration that requires classes (NestJS, Angular).
• DOM custom elements / web components (class MyElement extends HTMLElement).

For UI components in React: hooks-functional all the way. Vue’s Composition API + <script setup> is also class-less.

Gotchas

• #x outside the declaring class is a parse error, not a runtime one — can’t be conditionally accessed.
• #x in obj is the only safe brand check — instanceof can lie across realms (iframes, workers).
• Subclass access — #x is class-private, not protected. A subclass cannot access parent’s #x. Use TS protected (TS-only) or design via methods.
• Decorators can’t change the kind of thing — a class decorator returns a class; a method decorator returns a method. The runtime guards against returning the wrong shape.
• Decorator evaluation order — class decorators run after method decorators; bottom-up within each kind.
• static {} and await — top-level await doesn’t work inside a static block. Use an async IIFE if needed, or set up the static differently.
• Compile target matters — target: "ES2022" for native #x; older targets transpile to WeakMap (still private but with overhead).

Related

• TypeScript class typing: TypeScript — Senior Interview Prep
• React function components vs classes: React
• Iterators/generators (often paired with class implementations): Iterators and Generators (incl. for-await-of)

Further reading

• MDN — Private class features: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_properties
• MDN — static initialization blocks: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Static_initialization_blocks
• TC39 — Decorators: https://github.com/tc39/proposal-decorators
• TypeScript 5.0 — Decorators: https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#decorators