Decorators Status Update 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.

Decorators should have no per-class literal evaluation cost by design.
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.

Definition Static
Application Static
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

	// 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
	});
	})
	}

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

Decorators Status Update

Chris Garrett