Decorators Status Update

Chris Garrett

2020-06

Meeting Updates

  • Bi-weekly, Tuesdays at 10am PST (5pm UTC)
  • Next meeting is June 16th
  • Agenda doc in Reflector. Anyone can add items before the next meeting and join.
  • Open to TC39 members and invited guests

Design Space Updates

Decorators must be static

There is a one-time cost that is paid during parsing or the initial compile.

  1. Decorators should have no per-class literal evaluation cost by design.
  2. Engines should be able to generate code for decorators during the initial compile. That is, modules or class bodies should not need to be reparsed/recompiled.
  1. Definition Static
  2. Application Static
  3. Built-Target Static

1. Definition Static

Static through analyzable definition

// tracked.mjs

export decorator @tracked {
  @initialize((instance, name, value) => {
    instance[`__internal_${name}`] = value;
  })
  @register((target, name) => {
    Object.defineProperty(target, name, {
      get() { return this[`__internal_${name}`]; },
      set() { this[`__internal_${name}`] = value; this.render(); },
      configurable: true
    });
  })
}

Definition Static Design Space

  • Definitions must be statically analyzable
    • No arbitrary expressions
  • Definitions must decompose into a number of known operations
  • Definitions must be parsed before they are applied

2. Application Static

Static through exactly one meaning applying a decorator

function logged(enabled) {
  return () => {
    get(target, instance, prop, value) {
      return value
    },
    set(target, instance, prop, value) {
      if (enabled)
        console.log(prop, value)
      return value
    }
  }
}

Application Static Design Space

  • Decorators must have exactly one meaning
  • That meaning must boil down to a transform that is known ahead-of-time
  • Every decorated value can have a different meaning
    • Classes
    • Class Fields
    • Class Accessors
    • Class Methods

3. Build-Target Static

Static through desugaring decorators to a static output via build-tools

Build-Target Static Design Space

  • Decorator syntax still needs to be usable without transpilation/desugaring. Could be dynamic, as long as common use cases are compiled out by build tools. 
  • Decorators may have many meanings
  • Build tools may need to be able to agree on definitions of decorators ahead of time, or come up with some kind of community standard
  • Output-size is a constraint - adding too many bytes could be an issue
  • So far we've added a variety of concerns and constraints
  • Unclear if there is any way to solve every constraint as is

Ecosystem Audit

  • Examining top decorators libraries in the ecosystem today
  • Categorizing decorators by capabilities and behaviors
  • Goal is to gather data about most common use cases to help inform the design process